弱無狀態性以及/或者狀態保質期機制：即將到來

2021-03-12 18:03:26

以太坊基礎層接下來面臨的一大挑战就是處理日漸增加的狀態數據：當前以太坊區塊鏈的狀態數據約有 100 GB（其中就包括狀態樹節點數據），而且每年大約會增加 50GB。日益膨脹的狀態會讓同步以太坊區塊鏈、擔當區塊鏈的驗證者變得越來越困難，還有使網絡陷入中心化的風險；尤其，狀態數據的增長還有可能變得更快（因為區塊 Gas 上限可能進一步提高）。

現在，人們提出了兩類技術作為短期內的解決方案：

狀態保質期（State expiry）：從狀態中移除那些近期（比如過去一年）沒有被訪問的狀態對象，並且，在 “復活” 這些過期的狀態對象時需要提供（證明其存在性的）見證數據（witness）。這將使 每個節點 都要存儲的狀態數據限制在 20～50 GB。
弱無狀態性（Weak Statelessness）：僅要求區塊生產者（block proposer）存儲狀態，而所有其他節點都無需存儲狀態即可驗證區塊。

當然，也有更長期的選擇如 “完全無狀態性（full statelessness）”：可以認為是上述兩種方案的極端形式（你既可以把它當成是保質時長為 0 的狀態保質期方案，也可以當成是連區塊生產者也無需存儲任何狀態的弱無狀態性方案），但更具有挑战性，因此可以認為在短期內沒有投入太多時間的必要。

當然，狀態保質期方案和弱無狀態性也面臨許多挑战（見我最近的一篇文章（中文譯本）），不過，不論哪一種方案，近來都有可觀的進步，可以大大緩解我們面臨的困難。

關於狀態保質期方案，關鍵難點在於：

如何組織狀態的結構，使得不用的部分就會過期？（我們是在狀態樹上存儲 “存根”，還是把過期的狀態對象移到一個單獨的樹狀結構中，還是完全放到別的結構中？）我們是在账戶層實現它，還是在存儲槽層面實現它（我更傾向於在存儲槽層面實現狀態保質期方案（中文譯本））
滅活狀態對象時應採取什么樣的流程？尤其是，我們是接連不斷地滅活狀態對象，還是每隔一段時間（比如 1 年）實施一次滅活行動？“ReGenesis”就是後面這種策略的代稱（中文譯本）。
如何處理 “復活衝突（resurrection conflicts）” 問題？復活衝突是一個重要的概念。假設某些账戶或存儲槽在某些地址/位置創建好之後過期了；然後，該账戶/存儲槽又在相同的位置被重新寫入；最後，有些人又嘗試復活最初那個已經過期的對象。我們該如何解決這個過期又復活的狀態與那個新創建的狀態之間的衝突？我的文章有專門的一節詳細描述了這個問題。

至於弱無狀態性，關鍵難點在於：

如何使用 Gas 重定價來限制見證數據的上限？（EIP 2929 解決了大部分問題；然而一旦我們引入代碼默克爾化（中文譯本），就仍然需要為訪問每一個合約代碼塊施加成本）
見證數據的大小：見證數據即向無狀態的客戶端提供的、用於驗證區塊有效性的額外數據；這部分數據，即使有了合適的重定價措施，也有約 4 MB，對於我們這個每 13 秒就要廣播一次區塊的網絡來說，還是太大了。
事務的廣播：如果客戶端並不能直接訪問狀態來驗證事務本身的有效性（nonce 對不對、夠不夠 ETH 支付手續費），那事務要怎么在網絡間傳播、驗證呢？（譯者注：如果客戶端無法驗證自己收到的事務的有效性，將無論有效無效的事務都一視同仁地轉播，則這會變成一個阻塞 P2P 網絡的拒絕服務攻擊因素。）

幸運的是，近來兩種方法都取得了許多進展，這些進展似乎能解決絕大多數困擾：

一些技術能讓 ReGenesis 類型的（基於 epoch）的狀態保質期方案最小化復活衝突
Piper Merriam 研究了如何在事務廣播網絡中添加見證消息使之適合無狀態客戶端；以及分布式的狀態存儲和按需可得性
Verkle tree，可以將最糟糕情況下的見證數據大小從約 4 MB 降低到約 800 kB（這已經足夠小了，因為當前最糟糕情況下（全部是 calldata）的區塊可達到約 780 kB，而我們也不得不處理）。看幻燈片、文檔和代碼。

從理論到實際

兩種解決方案都在开發中，可能現在是時候要改觀、把它們當成是可行的路徑而非研究領域的概念了。至少有一個（可能最終是兩個）需要在以太坊上實現。

那這就產生了一個優先級問題：如果我們不得不在兩者中挑一個，哪一個更重要一些？Dankrad 分析了弱無狀態性；如果有詳細講解狀態保質期的工作，那對照起來必定會很有趣（我還沒發現有這樣的文檔；但也許有）。

另一個挑战是，讓整個生態准備好付出轉變的代價。舉些例子：

弱無狀態性需要用 verkle tree 來替代二進制樹（譯者注：原文如此。疑應為 “十六進制樹”，即當前的以太坊狀態樹所用的格式），這會使現今所有的默克爾分支驗證器（不論是客戶端和還是智能合約）失效
Verkle tree 也要求改變客戶端的同步協議
我們還需要添加按代碼塊計算的 Gas 成本（例如，每訪問 32 字節的代碼塊就需要消耗 500 Gas），這會讓某些應用的 Gas 开銷比當前的更大
狀態保質期方案需要應用重新設計自己的合約，以高效地使用新狀態（意思是，當前用於解決復活衝突問題的方案引入了 “舊狀態區域” 和 “新狀態區域” 的概念，在舊狀態區域創建一個新對象需要提交證明，且證明會隨時間推移而增大；而在新狀態區域創建對象則不需要證明，所以合約（例如 token 合約）需要新的版本和架構來處理這一點，雖然不更新也能繼續用，但這樣會更不便利，Gas 开銷也會更高）
依賴歷史數據訪問權的 dApp 需要切換到一些另外的協議/L2 機制（比如 The Graph？）中，以訪問 1 年以前的數據

好處

解決上述問題需要極大的毅力。但回報是豐厚的：

讓更多人能夠運行以太坊節點，幫助以太坊去中心化以及降低 “Infura 依賴風險”
啓用以太坊的無狀態驗證，大幅降低成為 PoS 驗證者的开銷：實現之後，節點甚至可以選擇性地驗證以太坊應用的數據，例如：僅驗證自己參與了見證（attesting）的區塊。這將使我們更接近我們夢寐以求的目標：保證用戶使用容易买到的消費級硬件（甚至是手機！）就能成為 PoS 驗證者並且長期不變
提高區塊 Gas 上限：縮減客戶端的狀態數據規模使我們能安全地大幅提高區塊 Gas 上线，為用戶提供更低的交易手續費。更小的狀態數據意味着這些數據甚至可以放到內存中，因此每次訪問狀態的實際开銷都會更小，因此我們有望安全地提高區塊 Gas 上限。
讓應用开發者更為確信，此番轉變之後，協議的經濟模型可以更堅固，而且未來不會再有太大改變，因為協議中主要的經濟激勵不兼容問題（用戶只需支付一次費用就可以永久存儲一個狀態對象）已經終結。

希望對該主題我們有更多的討論，盡快开始开發必要的准備工作，為解決我們的狀態問題、為更高的 L1 效率和可擴展性鋪平道路！

原文鏈接:

https://ethereum-magicians.org/t/weak-statelessness-and-or-state-expiry-coming-soon/5453

作者: Vitalik

翻譯: 阿劍