觀點 | 保持以太坊可擴展性和可持續性的兩種方案:「弱無狀態性」 和 「狀態

原標題:《觀點 | 一種狀態保質期和無狀態性的路線圖》 以太坊的狀態的規模正迅速增長。當前僅存儲狀態大概是 35 GB,如果加上默克爾證明就是 100 GB 了;而且現在預計每年都要增長

原標題:《觀點 | 一種狀態保質期和無狀態性的路線圖》

以太坊的狀態的規模正迅速增長。當前僅存儲狀態大概是 35 GB,如果加上默克爾證明就是 100 GB 了;而且現在預計每年都要增長這個數字的一半。此外,狀態存儲也是以太坊經濟模型的一個短板:在這個機制中,用戶只需付費一次就可以給共識節點施加永久的負擔。為了保持以太坊的可擴展性和可持續性,我們需要一些解決方案。

有兩種路徑,而且都已經存在很長時間了:「弱無狀態性」 和 「狀態保質期」:

狀態保質期:從狀態中移除近期(比如,去年)無人訪問的狀態對象,並要求在復活狀態對象時提供見證數據(witness)。可以將每個節點都需要存儲的狀態數據減少到扁平的約 20 ~ 50 GB。弱無狀態性:僅要求區塊提議者存儲狀態,其他節點都可無狀態驗證區塊。在實踐中,需要把狀態共識形式(從默克爾樹)切換到 「Verkle Tree」,以縮減見證數據的規模。

本文提出了一種多階段的方案,來同時實現這兩種方案。因為,可以證明,這會比按順序實現這兩個(無論什麼順序)容易很多。如果不實現 Verkle 樹,狀態保質期方案下就需要非常大的見證數據來證明一個舊狀態;如果不實現狀態保質期,切換到 Verkle 樹就需要一個一步到位的切換流程(例如 EIP 2584),這幾乎跟只實現狀態保質期一樣複雜。如果合二為一,同時進行,它們就解決了彼此面臨的挑戰:狀態保質期方案包含了每年創建一棵新狀態樹的機制,因此 Verkle 樹可以分階段逐步建構,而無需一個一步到位的切換流程,而 Verkle 樹也解決了見證數據規模的問題。

鏈接:「狀態保質期」 和 「無狀態性」 概念的歷史

無狀態客戶端的概念,於 2017 年始發於 ethresear.ch 論壇:https://ethresear.ch/t/the-stateless-client-concept/172(亦可見 EthHub)(中文譯本)狀態租金(狀態保質期的前身),始發於 2015 年:https://github.com/ethereum/EIPs/issues/35ReGenesis(Alexey Akhunov 的提議,可以認為是 狀態保質期 + 歷史過期 的一種形式):https://medium.com/@mandrigin/regenesis-explained-97540f457807 (中文譯本)Verkle 樹:https://notes.ethereum.org/_N1mutVERDKtqGIEYc-Flw(演講)約束見證數據的大小:https://www.youtube.com/watch?v=qQpvkxKso2E一種狀態規模管理理論(2021 年 2 月):https://hackmd.io/@vbuterin/state_size_management最小化復活衝突的狀態約束方案:https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739實現無狀態性和狀態保質期的路徑:https://hackmd.io/@vbuterin/state_expiry_paths

回顧:狀態保質期如何工作?

這裡所描述的是此提案的機制。

核心想法是,每個周期(比如以一年為一個周期)都會有一棵狀態樹,每當一個周期開始時,就初始化一棵空狀態樹,所有的狀態更新都寫到這顆狀態樹上。在一個周期內,所有的寫入都會發生在最新的狀態樹上(所以新樹和老樹可能會存儲同樣的信息,也可能會發生衝突;那麼總是以更新的樹為優先)。

觀點 | 保持以太坊可擴展性和可持續性的兩種方案:「弱無狀態性」 和 「狀態

- 注意:我之前曾把這個約長一年的狀態保質期周期稱為 「epoch」,現在都稱為 「period」,以免與信標鏈的術語相混淆 -

兩個關鍵原則是:

只能修改最新的那棵樹(也即對應於當前周期的樹)。所有更老的樹都不能再修改;更老的樹上的對象只能在更新的樹上創建副本,而且這些副本會取代更老的副本。可以預期全節點(包括區塊提議者)只會保存最近的兩棵樹,所以只有最近的兩棵樹上的對象才能不需要 witness 就能讀取。讀取更老的對象就需要提供見證數據了。

「見證數據」 就是一個簡短的證據,證明某個值(或者某一組值)存在於某棵樹的某個位置上,而且驗證的一方只需具有樹根即可。舉個例子,可以製作 一個 witness 來證明賬戶?0x124f...89ab?的存儲空檔?123?處在某時的狀態下,包含的值為?50;任何人都只需要這棵狀態樹的根值就可以驗證這個證據。

狀態保質期產生了一種混合的狀態機制:共識節點需要保存最近被人訪問和修改過的狀態,但可以使用基於見證消息的無狀態客戶端方法來驗證更老的狀態。也就是說,也可以維護一個 「歸檔節點」,存儲所有歷史狀態樹,或者?一個完全無狀態的節點,使用見證數據來驗證哪怕是最新的狀態。不過,gas 消耗量的結構和默認的網路格式,都要圍繞 「節點會存儲最近的兩棵狀態樹」 來開發。

路線圖

遷移將按階段來實現:

周期 1 硬分叉:需要一個硬分叉來開啟第一個周期(此前的則都算是第 0 個周期)。分叉之後,就會出現兩棵狀態樹:十六叉的帕特里夏樹(已凍結,不可再編輯)以及一棵新的 Verkle 樹(包含所有新的狀態 編輯/增加,還有舊狀態的副本)EIP 草案:https://notes.ethereum.org/@vbuterin/verkle_tree_eip地址擴張周期:地址從 20 位元組擴充到 32 位元組,而新地址的格式包含一個 「地址周期」 的概念(曾用名 「地址空間(address space)」)。這樣新合約就可以無需提供見證數據而直接寫入新的存儲空檔。這一步什麼時候做都可以,只需要在最終狀態保質期轉型完成之前就可以了,在周期 1 分叉之前或之後都可以。VB 的方案?:https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485Ipsilon 團隊的方案:https://notes.ethereum.org/@ipsilon/address-space-extension-exploration周期 2 硬分叉:需要一個硬分叉來開啟周期 2,並安排未來周期的時點。周期 0 的十六叉的帕特里夏樹將被一棵 Verkle 樹替換,客戶端僅存儲其狀態根。從這時開始,周期 0 的狀態將需要見證數據來訪問。並且,狀態保質期方案也算是完整實現了。EIP 草案:https://notes.ethereum.org/@vbuterin/state_expiry_eip

(完)

(文內有許多超鏈接,可點擊左下 」閱讀原文「 從 EthFans 網站上獲取)

原文鏈接:

https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal

作者: Vitalik

翻譯:?阿劍

—-

編譯者/作者:以太坊愛好者

玩幣族申明:玩幣族作為開放的資訊翻譯/分享平台,所提供的所有資訊僅代表作者個人觀點,與玩幣族平台立場無關,且不構成任何投資理財建議。文章版權歸原作者所有。

0

發表迴響