階段式同步在架構層面上是一個非常重大的改變(但沒有大改資料模式),我們在 2020 年 3 月至 7 月實現了這一功能。正是有了它,我們才能大幅(10 倍)壓縮同步時間。
在 2020 年 8 月,我們又發現了將狀態表示資料從 50 GB 縮減到 10 GB 的方法。
在 2020 年 9 月,“中間雜湊值” 功能的粒度做得更細,將計算狀態根雜湊的速度提升了 4 倍(從 200 ms 縮減到 50 ms),同時將其資料規模從 7 GB 減小到了 2.5 GB.
當前我們正在開發合適的日誌索引(indexing of logs)
那麼,這一切到底意味著什麼呢?
其實,這都不意味著什麼,因為當前的實現還沒有到達效率的極限。
還有幾個 “未解之謎”:
1. 對久遠歷史中的狀態的默克爾證明還無法高效生成(對近期歷史的默克爾證明的生成效率是沒問題的。可以透過引入中間雜湊值的快照來緩解(這些資料相對來說也不大)
2. 一些共識計算無法與階段性同步協調工作,理想情況下,應該共同設計兩者
Silkworm
建立一個符合 Apache 2.0 協議、用 C++ 實現的模組化以太坊實現的想法,始於 2019 年初,因為那時我們看到 “Aleth” 專案基本上已經被放棄了。
但那並不是一個好時機。
到了 2020 年 5 月~6 月,時機終於到來。出現了 4 大轉機:
1. 我們從 BoltDB 切換成了 LMDB(用 C 語言實現的資料庫),這就能保證 Turbo-Geth 和 Silkworm 之間的資料庫相容性。
2. 階段式同步模式 自然而然地 將實現分解成了相對獨立的元件,這些元件基本上都透過資料庫中的記錄來互動(或者說透過記憶體中的 page 來互動,如果互動都發生在一個資料庫的事務內的話)。這就意味著,我們可以逐個逐個元件建立 C++ 實現。
3. 更早的 EVM 實驗(使用 EVMC 介面)暴露出了使用跨語言介面的巨大開銷,而 EVMC 的雙重介面又加劇了這一點。
4. 我們覺得已經有了足夠的經驗,能在一個可預期的時間內(1 年內,而不是 5 到 10 年)、靠著一些專家的幫助,就能完成這一切了。
未來
啟動 Silkworm 專案也開啟了我們的思路,比如我們可以把實現逐個逐個地遷移到其它程式語言(比如 Rust) 上。
我相信,以太坊 1.0 即使不引入分片,也能擴充套件至少 10 倍的吞吐量。我們主要面臨三個方面的挑戰:
1. 區塊的 Gas 上限更高會更容易招致 DOS 攻擊。Turbe-geth 的安全極限可能是其它實現的 10 倍高;而 Silkworm 可能會更高。
2. 更高的 Gas 上限會產生(資料量)更大的區塊。這就會反過來產生兩個問題:
a)區塊傳輸問題。這可以透過預先共識來處理(本質上就是犧牲交易時延來換取交易吞吐量)
b)區塊下載和儲存問題。可以透過使用專門化的儲存網路比如 BitTorrent 來解決(這些工作已經在進行中)。