一文了解如何通過ReGenesis改進以太坊網絡
編者按：本文來自以太坊愛好者（ID：ethfans）編者按：本文來自
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
圖片描述
以太坊愛好者（ID：ethfans）
DeFi 應用中鎖定的資金量已超過15 億美元；幾乎每天都有新的dApp 官宣。照這個速度下去，以太坊可能會死於太過成功。就基礎設施層而言，狀態無限增長是一大難題。
圖片描述
幾天之前，Alexey 在EthResearch 論壇上發布了一篇文章，提出了一個有趣的設想，並將其命名為ReGenesis 。
這個設想比較簡單，乍看之下可能會讓人覺得很激進：定期（例如，每100 萬個區塊）刪除存儲在本地的所有狀態，保留最新區塊的根哈希，然後重新開始構建狀態，再過100 萬個區塊之後，進行下一次狀態清零。
圖片描述
-ReGenesis ：每N 個區塊重設狀態。隨著狀態增長，需要的證明越少，直到下一個ReGenesis 啟動-
要想理解這個設想為什麼可行且值得研究，你需要先了解一些背景知識和講解。
這就是本文的主題。
目前情況
1. 狀態存儲集中化
在以太坊上發送交易非常容易，你自己不需要用到什麼狀態數據。交易發送者沒有保存任何狀態的動力。
如果你（礦工或交易所）正在運行一個基礎設施節點，你需要確保自己擁有驗證及廣播交易所需的一切狀態。如果你是礦工，你還需要更多狀態。
因此，當前狀態存儲都集中於大型實體（Infura、大礦工、交易所等）運行的基礎設施節點。
2. 狀態繼續無限增長
截至發稿時（6 月29 日），Turbo-Geth 客戶端中的“當前狀態” 大約40 GB ，而且還在繼續增長。
這裡的問題並不在於狀態大小本身，而在於狀態增長不受限制。當然了，我們也可以祈禱固態硬盤容量的增長速度超過區塊鏈狀態。
到目前為止，我們還算幸運，不過單憑運氣絕非長久之計。
對於無狀態以太坊計劃來說，對區塊見證（witness）定價是非常困難的。這些見證是由礦工生成的，交易發送方在發送交易時很難預測區塊見證的大小。
因此，我們需要在不影響現有智能合約的情況下，找到一種能夠通過智能合約行為推測見證價格的方法。
目前已經有了一些提案，如，Oil ，不過這確實是個棘手的問題。
好了，現在我們都知道了，要將所有當前狀態清零，只保留根哈希。數據量從40 GB 減少到32 字節。
這時，無狀態以太坊就派上了用場。為了能夠運行交易，你需要提供見證。見證包含所用賬戶、代碼和合約存儲內容，以及能夠用來驗證根哈希的默克爾證明（點擊此處，了解更多關於見證和無狀態以太坊的信息）。
然而，ReGenesis 和Stateless Ethereum 之間有一個區別。在解釋這個區別之前，我想先介紹兩個術語：顯式狀態（explicit state）和隱式狀態（implicit state）。
圖片描述
- 現行的以太坊：假設兩個節點擁有一切必需狀態 -
在無狀態以太坊中，當你運行一個節點時，對等節點向你發送了一個新的區塊N，並且認為你在任何情況下都沒有隱式狀態。它們會將你運行區塊N 所需的一切都打包進區塊N 。這就是區塊見證（block witness）。
圖片描述
你的對等節點向你發送顯式狀態。
圖片描述
圖片描述
假設ReGenesis 在區塊10.000.000 啟動。目前，位於區塊鏈頂端的是區塊10.001.000 。我們可以認為任何ReGenesis 節點都擁有區塊10.000.000 和區塊10.001.000 之間所有數據的隱式狀態。這些區塊中用到的每個賬戶、每個存儲條目和每個合約已經存儲在每個節點上，因此不需要區塊見證。這樣就可以大幅削減見證的大小，正如我們在準-無狀態同步實驗中看到的那樣。
圖片描述
圖片描述
- ReGenesis：區塊1 提供節點1 所缺少的信息 -
圖片描述
- ReGenesis：將來自區塊1 的狀態合併到節點1 的隱式狀態中 -
如果你（作為交易發送方）需要將新的交易發送到當前區塊高度為10.001.000 的網絡，你需要執行以下步驟：
創建你想要的交易；
為不包含在隱式狀態內的條目創建顯式狀態，將其打包為交易見證（下文會作詳細討論）；將帶有見證的交易發送至網絡；
如果你想在ReGenesis 啟動後發送交易，你可能需要擁有一些ReGenesis 啟動前的狀態信息，才能生成見證。
圖片描述圖片描述
圖片描述圖片描述
圖片描述- 組合式區塊見證 -
圖片描述
圖片描述
- 交易見證 -
圖片描述
- 區塊見證是由礦工生成的。我們需要通過複雜的Gas 定價機制來補償他們 -
交易見證有一個很重要的優點。它們是由交易發送方生成的，與交易一起發送。因此，我們可以立即知道交易見證的大小以及如何為其定價。我們不需要通過EVM 來重新定價。
- 交易見證是由交易發送方生成的，補償起來容易得多 -
一級標題
使用交易見證的一個潛在缺陷是數據複製。假設一個區塊中的所有交易都由兩個相同的賬戶達成，交易見證內將包含重複的數據。
區塊見證由礦工生成。礦工知道區塊中交易的確切順序，因此區塊見證總是包含最新數據。
一級標題
交易見證來自交易發送方。因此，應該有一個智能合併機制，將交易見證與區塊中較早的交易所生成的隱式狀態合併起來。
一級標題
為什麼我們現在還無法使用交易見證？
具體來說，在無狀態以太坊中，你需要提供這個交易的完整狀態，我們假定接收方沒有任何狀態。如果你的交易使用DSA ，那麼你的代碼讀取哪些存儲部分取決於代碼其他部分的值。
一級標題
從理論上來說，這就有可能招致DoS 攻擊。
如果Alice 提供了一個包含A 的證明，Bob 可以在Alice 的交易被打包之前更改K ，導致Alice 交易失敗。如果Alice 提供了一個包含B 的證明，Bob 可以故技重施。
一級標題
一級標題
結論
為了緩解這個問題，無論交易是成功還是因狀態不足失敗，我們都要確保我們所提供的證明被包含在狀態中。
一級標題
結論
雖然Alice 的交易失敗，但是該交易將路徑A 所需的一切證明都添加到了節點的隱式狀態中。
一級標題
結論
現在，Alice 可以重新發送這筆交易，提供路徑B 所需的證明。 Bob 無法再通過更改K 來阻止Alice 的交易，即使他通過更改K 來讓交易選擇路徑A ，那也太遲了，路徑A 所需的證明已經包含在了節點的隱式狀態中，因此交易無需任何證明即可發送至節點。如果交易被導向路徑B ，那麼它正好擁有B 所需的證明。
一級標題
結論
最後，讓我們來快速回顧一下ReGenesis 的設想和要點：
每生成N 個區塊，我們就會將所有狀態清零，只保留根哈希；
ReGenesis 啟動的頻率不能太高，可以設定為每100 萬個區塊、每1000 萬個區塊等；
交易發送者需要提供顯式狀態（作為交易見證）；
