Turbo-Geth 作為一個純粹出于好奇心的項目，始于 2017 年（沒錯，就是在 CryptoKitties 導(dǎo)致的瘋狂擁堵時期）。一開始是為了探究基于 trie 的數(shù)據(jù)庫模式的替代方案。在 2018 年 3 月，Turbo-Geth 項目從以太坊基金會處獲得了一筆小額的獎金（2.5 萬美元）。

在 2019 年第一第二季度，Turbo-Geth 被用作狀態(tài)租金（State Rent）研究的狀態(tài)分析平臺。到了 2019 年第三第四季度，Turbo-Geth 也被用于執(zhí)行無狀態(tài)以太坊的回溯檢驗（back testing）。在 Devcon5 舉辦以前，我認為它在概念上已經(jīng)很可靠了。

在 Devcon5 上，我提議在一年內(nèi)不再接受 EIP，好把所有的實現(xiàn)都轉(zhuǎn)成類似的數(shù)據(jù)模式。但因為大家有所懷疑，而且 「核心開發(fā)者」 團體也沒有這個積極性，我的提議沒有被采納。

懷疑意見主要圍繞著高效計算和更新狀態(tài)根哈希的方法。在 2020 年 3 月 的 EthCC 2020 大會上，我們提出了解決方案：額外的數(shù)據(jù)結(jié)構(gòu)，叫做 「中間哈希值（Intermediate Hashes）」。接下來幾個月里我們就完全實現(xiàn)了這個方案。

階段式同步（staged sync）的想法來自于對按表寫入變更量（per-table write churn）的測量值的觀察。對數(shù)據(jù)變更（churn）的解決的方案是在一個預(yù)先排序號的序列中插入數(shù)據(jù)。我們在 2019 年末仔細觀察了這些現(xiàn)象，但我們的第一個實驗性的實現(xiàn)在 2020 年 2 月才表現(xiàn)出有重大的性能優(yōu)勢。

階段式同步在架構(gòu)層面上是一個非常重大的改變（但沒有大改數(shù)據(jù)模式），我們在 2020 年 3 月至 7 月實現(xiàn)了這一功能。正是有了它，我們才能大幅（10 倍）壓縮同步時間。

在 2020 年 8 月，我們又發(fā)現(xiàn)了將狀態(tài)表示數(shù)據(jù)從 50 GB 縮減到 10 GB 的方法。

在 2020 年 9 月，「中間哈希值」 功能的粒度做得更細，將計算狀態(tài)根哈希的速度提升了 4 倍（從 200 ms 縮減到 50 ms），同時將其數(shù)據(jù)規(guī)模從 7 GB 減小到了 2.5 GB.

當(dāng)前我們正在開發(fā)合適的日志索引（indexing of logs）

那么，這一切到底意味著什么呢？

其實，這都不意味著什么，因為當(dāng)前的實現(xiàn)還沒有到達效率的極限。

還有幾個 「未解之謎」：

對久遠歷史中的狀態(tài)的默克爾證明還無法高效生成（對近期歷史的默克爾證明的生成效率是沒問題的。可以通過引入中間哈希值的快照來緩解（這些數(shù)據(jù)相對來說也不大）

一些共識計算無法與階段性同步協(xié)調(diào)工作，理想情況下，應(yīng)該共同設(shè)計兩者

Silkworm

創(chuàng)建一個符合 Apache 2.0 協(xié)議、用 C++ 實現(xiàn)的模塊化以太坊實現(xiàn)的想法，始于 2019 年初，因為那時我們看到 「Aleth」 項目基本上已經(jīng)被放棄了。

但那并不是一個好時機。

到了 2020 年 5 月～6 月，時機終于到來。出現(xiàn)了 4 大轉(zhuǎn)機：

我們從 BoltDB 切換成了 LMDB （用 C 語言實現(xiàn)的數(shù)據(jù)庫），這就能保證 Turbo-Geth 和 Silkworm 之間的數(shù)據(jù)庫兼容性。

階段式同步模式_自然而然地_將實現(xiàn)分解成了相對獨立的組件，這些組件基本上都通過數(shù)據(jù)庫中的記錄來交互（或者說通過內(nèi)存中的 page 來交互，如果交互都發(fā)生在一個數(shù)據(jù)庫的事務(wù)內(nèi)的話）。這就意味著，我們可以逐個逐個組件創(chuàng)建 C++ 實現(xiàn)。

更早的 EVM 實驗（使用 EVMC 接口）暴露出了使用跨語言接口的巨大開銷，而 EVMC 的雙重接口又加劇了這一點。

我們覺得已經(jīng)有了足夠的經(jīng)驗，能在一個可預(yù)期的時間內(nèi)（1 年內(nèi)，而不是 5 到 10 年）、靠著一些專家的幫助，就能完成這一切了。

未來

啟動 Silkworm 項目也打開了我們的思路，比如我們可以把實現(xiàn)逐個逐個地遷移到其它編程語言（比如 Rust） 上。

我相信，以太坊 1.0 即使不引入分片，也能擴展至少 10 倍的吞吐量。我們主要面臨三個方面的挑戰(zhàn)：

區(qū)塊的 Gas 上限更高會更容易招致 DOS 攻擊。Turbe-geth 的安全極限可能是其它實現(xiàn)的 10 倍高；而 Silkworm 可能會更高。

更高的 Gas 上限會產(chǎn)生（數(shù)據(jù)量）更大的區(qū)塊。這就會反過來產(chǎn)生兩個問題：

• 區(qū)塊傳輸問題。這可以通過預(yù)先共識來處理（本質(zhì)上就是犧牲交易時延來換取交易吞吐量）

• 區(qū)塊下載和存儲問題。可以通過使用專門化的存儲網(wǎng)絡(luò)比如 BitTorrent 來解決（這些工作已經(jīng)在進行中）。

﹏

﹏

﹏

﹏

推薦閱讀

或是未來10年最強風(fēng)口：產(chǎn)業(yè)區(qū)塊鏈時代正式到來

區(qū)塊鏈落地應(yīng)用盤點：五大領(lǐng)域應(yīng)用告訴你“區(qū)塊鏈能做什么”

區(qū)塊鏈將引爆跨學(xué)科研究，比特幣只是第一顆“核彈”

5分鐘看懂區(qū)塊鏈如何提升中國企業(yè)活力與效能！

一文讀懂區(qū)塊鏈項目的法律問題，通證激勵、鏈改可行嗎？

比特幣技術(shù)堆棧的創(chuàng)新：今非昔比

區(qū)塊鏈入門 | 什么是DAO？

更多關(guān)鍵詞：礦工?|?51%攻擊

燃點?|?孟巖?|?白碩?|?肖風(fēng)

長鋏?|?李國權(quán)?|?螞蟻金服?|?來學(xué)嘉

總結(jié)

以上是生活随笔為你收集整理的不用分片也能扩展 10 倍性能？简单了解以太坊 Turbo-Geth 客户端的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。