引介EIP-4444:如何對執行層客戶端的歷史數據設限

EIP-4444 提議客戶端修剪超過1 年的數據。那麼,為什麼我們不直接修剪數據呢?

譯者註:EIP-4444 提議把HISTORY_PRUNE_EPOCHS 設為82125 個epoch (即信標鏈上1 年),使得在PoS 以太坊裡執行層客戶端不再在p2p 網絡上提供超過一年的區塊頭、區塊主體和收據的數據,客戶端可以在本地修剪這些歷史數據。此EIP 的作者之一@lightclients 在推特寫了簡介,本文為該推文的翻譯。

以太坊客戶端目前存儲著275 GB 的歷史數據,這些數據對於驗證區塊鍊是不必要的。這個數字正在以每年140 GB 的速度增長。 EIP-4444 提議客戶端修剪超過1 年的數據。那麼,為什麼我們不直接修剪數據呢?

要理解為什麼數據還沒被修剪,以及為什麼這需要討論,就需要理解歷史數據今天是如何被使用的。有兩個主要的使用類別:同步和用戶通過JSON-RPC 請求。

在同步裡有兩種主要方法:

  • 完全同步(Full Sync):下載並執行從創世直到區塊鏈頂端的每個區塊

  • 狀態同步(State Sync):這裡有很多方案,但主要是用工作量證明檢查進行區塊頭同步,並下載最新區塊的狀態。

在這兩種情況下,客戶端通過p2p 網絡請求歷史數據,以延長它們對鏈的視域(view)。信任模型通常是信任創世狀態然後驗證其他所有東西——要么完全驗證,要么通過工作量證明檢查進行輕度驗證。

權益證明改變了這點。因為它容易遭受遠程攻擊,我們必須依賴“弱主觀性檢查點(Weak Subjectivity Checkpoint)”。這實質上是我們對權威鏈上一個區塊的信任程度等同於對PoW 裡創世區塊的信任。

弱主觀性檢查點使得客戶端可以跳過通過p2p 網絡請求歷史數據的引導步驟。當然,在檢查點後它們將仍然需要同步歷史數據——因此檢查點應該總是在修剪邊界之前。

這聽上去像是安全性上的倒退。以前,我們有一個2015 年7 月13 日的哈希值做驗證。現在,我們有的是變動著的弱主觀性檢查點。但事實上,我們一直都依賴弱主觀性。

你最後一次驗證客戶端版本間的代碼差異是什麼時候?大多數人沒有技術背景來做這件事。因此,每次你更新你的客戶端,你都依賴你的客戶端團隊嚴格地實現以太坊協議。

幸運的是,有很多人盯著像go-ethereum 這樣的軟件。只需要一個吹哨者就能揭發代碼裡的惡意提交。同樣,只需要有一個吹哨者指出一個客戶端推出一個惡意的弱主觀性檢查點。

事實上,驗證一個客戶端推出正確的弱主觀性檢查點比確保代碼正確執行協議要容易得多。

因此,從安全性的角度來看,其實是沒有倒退的。這也包括同步——歷史數據所需的另一個主要用途類別是為用戶請求提供服務。

用戶可以請求兩種類型的數據:

  • 當前數據,例如存儲槽的數值、賬戶餘額、最新的區塊高度等

  • 歷史數據,例如在區塊N 的存儲槽數據、區塊N 的區塊頭、交易收據等

當前的數據將繼續可以被訪問,當實現EIP-4444 後,歷史數據能否被訪問取決於它是多長時間以前的。

歷史數據的主要使用者是dapp 開發者。很多dapp 添加歷史數據到它們的數據庫,通過它們的前端提供給用戶。對於他們來說,能夠遍歷所有交易和日誌是很重要的。

支持這個用例有多個方法——現在最受歡迎的方法是客戶端發布多路復用器,支持一定範圍區塊的版本會執行該範圍的區塊。例如,geth 版本A 可能支持直到區塊高度為10m 的區塊,而geth 版本B 則支持10m 之後的區塊。

多路復用器將用版本A 執行區塊高度為0 到10m 的區塊,輸出狀態數據庫並將其導入geth 版本B,然後繼續執行10m 之後的區塊。 JSON-RPC 請求會被導向有合適信息響應的客戶端。

但是,如果歷史區塊在p2p 網絡上不再可得——那誰來提供這些數據?預計會有很多大型、受信任的機構提供這些數據的鏡像。由於數據是靜態的,所以很容易就其哈希值達成共識並進行驗證。這是1-of-N 的信任模型。

新標準將是不存儲歷史數據並運行一個客戶端多路復用器。這意味著以太坊客戶端的標準內存佔用會減少275 GB——但還有最後一個問題需要提及。

當前,當請求的數據不存在時,以太坊的JSON-RPC 會給一個空響應。假設客戶端沒有在同步,這會以“這個數據不存在於權威鍊或最近的分叉”被接受。

一旦客戶端開始修剪舊數據,這種不變性就會被打破。當一個用戶請求一個特定交易收據時,客戶端將不知道該收據是被修剪了還是從來沒有存在過。目前,我們期望RPC 將對這兩種情況返回一個空響應。

我很想得到關於這種方法的反饋。 JSON-RPC 的使用者對此有什麼看法?你們訪問超過1 年的歷史數據的頻率如何?另一種方法(儘管更重) 是保持一個被修剪數據哈希值的索引,這樣可以向用戶返回更多的內容。

275 GB 這個數據是在geth db inspect 的輸出裡查到的。下面是截圖:

正式的EIP-4444 (順便提一下,讀作EIP four 4s) 規範可以在這裡找到:

https://t.co/vlfYfcIGpN?amp=1

來源:@lightclients

展開全文打開碳鏈價值APP 查看更多精彩資訊

Total
0
Shares
Related Posts