Beam Sync：同步以太坊節點的新方法
編者按：本文來自：以太坊愛好者（ID：ethfans）以太坊愛好者（ID：ethfans）
以太坊愛好者（ID：ethfans）
正文
以太坊愛好者（ID：ethfans）
，作者：Jason Carver，翻譯& 校對: 陳亮& 阿劍，Odaily經授權轉載。
為什麼要改善節點同步體驗？
一級標題
一級標題
二級標題
Full Sync（完全同步方法）
二級標題
二級標題
Fast Sync（快速同步方法）
Full Sync（完全同步方法）
在快速同步可以執行啟動塊之前，需要的區塊狀態包括：合約字節碼、帳戶和合約存儲內容。執行交易時可能需要讀取所有這些值中的任何一個。因此，快速同步方法要求從其他對等節點處獲得啟動塊之前的狀態快照。快照是用狀態根哈希值來標記的；所謂狀態根哈希值，就是所有狀態內容的哈希默克爾樹根值。節點使用該狀態根哈希來驗證從其他對等節點處下載的狀態數據是否與礦工在該區塊中聲明的狀態相匹配。
二級標題
其他方法
二級標題
一級標題
快速同步方法有多快？
一級標題
一級標題
一級標題
概述
Beam 同步方法
二級標題
二級標題
概述
二級標題
二級標題
二級標題
隨著時間的推移，缺少的數據會越來越少。注意，如果某個狀態從未被訪問過，那麼客戶端將永遠不會請求它（因此永遠也不會獲得這部分狀態數據），因此我們在後台運行另一個進程來填補這些空白。通過該回填過程，Beam 同步最終會取得所有狀態數據並保存在本地，然後節點就可以切換到完全同步狀態。
為了簡單起見，我們用“區塊見證數據大小” 來指稱執行區塊所需的數據元素數量。這類數據元素可能是在主要賬戶狀態樹上的一個節點，或者是合約存儲樹上的一個節點，或者是某個合約的完整字節碼（譯者註：此處說的“狀態樹”、 “存儲樹” 都是默克爾樹結構的數據）。
二級標題
Beam 同步的速度提升
二級標題
分析區塊見證數據大小是理解Beam 同步方法性能的關鍵。快速同步方法必須在執行第一個區塊（即啟動塊）之前下載全部狀態數據，而Beam 同步僅需要下載一個區塊的見證數據，如果所下載的區塊見證數據包含完整狀態的三分之一，那麼Beam 同步的運行效率將大約是快速同步的三倍。
所以，顯然，下一個步驟是看主網的見證數據實際是多大。可能直接下結論還為時尚早，但是早期試驗結果表明3000 個狀態樹節點的數據量是一個合理的估計（90% 置信度）。而主網的全部狀態信息有超過3 億個樹節點。
Beam 同步的速度提升
讓我們新定義一個標準：“從啟動到執行” 的時間。這是從用空數據庫啟動節點到完成最近一個區塊的完全導入所需的時間。
但是，Beam Sync 方法往往無法真正做到10 萬倍提升。理由包括但不限於：
二級標題
區塊見證數據是按需確定的，這就意味著我們無法提前預知需要哪些狀態數據（收到一個數據，才能確定下一個需要的數據是什麼）。所以我們向對等節點請求數據時，一次只能請求一個狀態數據。相反，快速同步一次最多可請求384 個樹節點，這使得Beam 同步對對等節點的網絡延遲更敏感。
尋找高質量，低延遲的同步節點需要花些時間。說實在的，會遇上什麼樣的對等節點，那是真·隨機事件。
Beam Sync Pivot
與快速同步方法不同，Beam 同步方法會持續下載啟動塊之後的區塊狀態，這樣也會拖慢區塊導入時間。如果你對這一點有一些直觀認識，那麼你可能會注意到，如果收集區塊見證的平均時間比區塊生產的平均時間還要長，那問題會更加嚴重。
Beam 同步滯後性
二級標題
二級標題
二級標題
一級標題
一級標題
二級標題
好了，讓我們看看真實的情況是什麼樣。
二級標題
Trinity 客戶端上的Beam 同步
二級標題
註釋：把區塊Gas Limit 從8M 提升到10M 似乎會增加平均滯後時間，伊斯坦布爾升級後可能會減少滯後時間，因為提高了在區塊鏈上寫入狀態數據所需的gas 耗費量。
剩下的工作
二級標題
懸而未決的問題基本上都會在日常開發中暴露出來，所以這些問題都是“後台日誌上的bug”。在這一點上，可以說，沒有人擔心Beam Sync 會不會是一個難以企及的夢想。這種對Beam 同步的信心是嶄新的。但我們也認為未來有可能有突發的未知問題亟待解決，就像一個月前一樣！
一級標題
剩下的工作
一級標題
