Turbo-Geth 作為一個純粹出於好奇心的專案，始於 2017 年（沒錯，就是在 CryptoKitties 導致的瘋狂擁堵時期）。一開始是為了探究基於 trie 的資料庫模式的替代方案。在 2018 年 3 月，Turbo-Geth 專案從以太坊基金會處獲得了一筆小額的獎金（2.5 萬美元）。
在 2019 年第一第二季度，Turbo-Geth 被用作狀態租金（State Rent）研究的狀態分析平臺。到了 2019 年第三第四季度，Turbo-Geth 也被用於執行無狀態以太坊的回溯檢驗（back testing）。在 Devcon5 舉辦以前，我認為它在概念上已經很可靠了。
在 Devcon5 上，我提議在一年內不再接受 EIP，好把所有的實現都轉成類似的資料模式。但因為大家有所懷疑，而且 「核心開發者」 團體也沒有這個積極性，我的提議沒有被採納。
懷疑意見主要圍繞著高效計算和更新狀態根雜湊的方法。在 2020 年 3 月 的 EthCC 2020 大會上，我們提出瞭解決方案：額外的資料結構，叫做 「中間雜湊值（Intermediate Hashes）」。接下來幾個月裡我們就完全實現了這個方案。
階段式同步（staged sync）的想法來自於對按表寫入變更量（per-table write churn）的測量值的觀察。對資料變更（churn）的解決的方案是在一個預先排序號的序列中插入資料。我們在 2019 年末仔細觀察了這些現象，但我們的第一個實驗性的實現在 2020 年 2 月才表現出有重大的效能優勢。
階段式同步在架構層面上是一個非常重大的改變（但沒有大改資料模式），我們在 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）
那麼，這一切到底意味著什麼呢？
其實，這都不意味著什麼，因為當前的實現還沒有到達效率的極限。
還有幾個 「未解之謎」：
對久遠歷史中的狀態的默克爾證明還無法高效生成（對近期歷史的默克爾證明的生成效率是沒問題的。可以透過引入中間雜湊值的快照來緩解（這些資料相對來說也不大）
一些共識計算無法與階段性同步協調工作，理想情況下，應該共同設計兩者Silkworm
建立一個符合 Apache 2.0 協議、用 C++ 實現的模組化以太坊實現的想法，始於 2019 年初，因為那時我們看到 「Aleth」 專案基本上已經被放棄了。
但那並不是一個好時機。
到了 2020 年 5 月～6 月，時機終於到來。出現了 4 大轉機：
我們從 BoltDB 切換成了 LMDB （用 C 語言實現的資料庫），這就能保證 Turbo-Geth 和 Silkworm 之間的資料庫相容性。
階段式同步模式_自然而然地_將實現分解成了相對獨立的元件，這些元件基本上都透過資料庫中的記錄來互動（或者說透過記憶體中的 page 來互動，如果互動都發生在一個資料庫的事務內的話）。這就意味著，我們可以逐個逐個元件建立 C++ 實現。
更早的 EVM 實驗（使用 EVMC 介面）暴露出了使用跨語言介面的巨大開銷，而 EVMC 的雙重介面又加劇了這一點。
我們覺得已經有了足夠的經驗，能在一個可預期的時間內（1 年內，而不是 5 到 10 年）、靠著一些專家的幫助，就能完成這一切了。未來
啟動 Silkworm 專案也開啟了我們的思路，比如我們可以把實現逐個逐個地遷移到其它程式語言（比如 Rust） 上。
我相信，以太坊 1.0 即使不引入分片，也能擴充套件至少 10 倍的吞吐量。我們主要面臨三個方面的挑戰：
區塊的 Gas 上限更高會更容易招致 DOS 攻擊。Turbe-geth 的安全極限可能是其它實現的 10 倍高；而 Silkworm 可能會更高。
更高的 Gas 上限會產生（資料量）更大的區塊。這就會反過來產生兩個問題：
區塊傳輸問題。這可以透過預先共識來處理（本質上就是犧牲交易時延來換取交易吞吐量）
區塊下載和儲存問題。可以透過使用專門化的儲存網路比如 BitTorrent 來解決（這些工作已經在進行中）。
