狀態可得性：GetNodeData DHT 方案

我的團隊正在驗證一個 “狀態可得性” 問題的解決方案是否可行。

方案概述

我們的方向大致如下：

• 網絡是一個分布式哈希表（DHT，很可能構建在 discv5 上）。

• 账戶和合約存數據存儲在它們各自的 trie 節點中。

• 網絡中的節點擁有所有區塊頭數據。

• 每個區塊中新的 trie 數據都以證明的形式發送到網絡中。

我們將這個方案稱為GetNodeData方案，因為它與快速同步方案（fast sync）獲取狀態的方式差不多。

trie 節點 vs 葉節點 + 證明存儲

我們選擇將數據存儲在各個 trie 節點中，因為這樣比較簡單。

另一種方法是僅存儲葉子節點的值和附帶的證明。這個方法比較復雜，因為證明需要不斷更新。更新證明可以在本地完成，但是需要進行 EVM 計算並廣播完整的區塊見證消息。EVM 計算成本很高，而完整的區塊見證消息很大。

通過將數據存儲在各個 trie 節點中，網絡節點只需存儲這些 trie 數據，並驗證新數據的默克爾證明即可。

迄今為止的發現

預期延遲

基於 DiscV5 DHT 的經驗，我們預期網絡查詢時間約為 100 毫秒。

每筆交易的 Trie 節點

Nick Gheorghita 一直在研究常見交易類型所涉及的 trie 節點的數量。在樣本數量較少的情況下，他得到的初步結果是：

• 簡單價值轉移：～ 30 個 trie 節點

• ERC20 轉账/批准：～ 50 個 trie 節點

如果延遲為 100 毫秒，則執行eth_estimateGas和eth_call需要的時間上限分別為 3 秒和 5 秒。我們還可以通過一些基礎的優化（如同時查找交易的發送方和接收方）來降低延遲。

我們正在進行更深入的實驗，來測量大型主網交易區塊的延遲情況。

垃圾回收和冷狀態

Brian Cloutier 已經對冷狀態訪問模式進行了一些調查。

關於冷狀態的定義，請參見這張術語表。

（冷狀態：指的是在較長一段時間內無人接觸（讀取或修改）的那部分狀態。）

Brian 的發現是，大多數區塊都會觸及之前 100 萬個區塊都沒有觸及的狀態（關於這一發現，Brian 可以給出詳細論證）。

這就涉及到垃圾回收。

• 如果網絡有足夠的空間存儲完整的歸檔狀態，我們就不需要垃圾回收。

• 如果網絡沒有足夠的空間來存儲完整的歸檔狀態，則該網絡必須執行某個機制來防止冷狀態丟失。

待解決問題

重復數據刪除和垃圾收集

存儲 trie 相同的兩個合約擁有同樣的 trie 節點。

同樣地，余額、nonce、代碼和狀態相同的兩個账戶的账戶數據也存儲在同樣的葉節點上。如果我們使用節點哈希作為鍵來存儲節點，必須通過引用計數（reference counting）來實現垃圾收集，否則就無法知道從一個 trie 中移除的節點有沒有在另一個 trie 中使用。

一種解決方法是，將節點在 trie 中的位置及其節點哈希作為鍵。這樣可以使用排除證明來刪除節點，但是會因為需要存儲重復數據而造成額外的成本。

一個待解決問題是，這會在多大程度上提高存儲需求。

歸檔 vs 垃圾收集

我們需要想清楚如何實現垃圾回收，或者說，確認網絡是否可以成為歸檔節點。

解決垃圾回收問題的方案：

1. 移除重復數據刪除機制，並使用(trie_path, node_hash)作為鍵來查找數據。

2. 監控網絡並主動重新添加冷狀態。

3. 弄清楚垃圾回收的子集是否可以僅發生在账戶 trie 中的中間 trie 節點上。

4. 確保網絡能夠像歸檔節點那樣運行。

數據入站

我們需要將新創建的 trie 數據推送到網絡中。網絡中的節點預期會存儲所有區塊頭的最新快照，從而將證明與最新狀態根錨定。

待解決問題有：

1. 新的 trie 數據的完整區塊證明有多大？

2. 區塊證明中每個節點各自的證明有多大？

原文鏈接:

https://ethresear.ch/t/state-availability-getnodedata-dht-approach-dev-update/8657

作者:  Piper Merriam

翻譯&校對: 閔敏 & 阿劍

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。