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

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

在 Devcon5 上，我提議在一年內(nèi)不再接受 EIP，好把所有的實(shí)現(xiàn)都轉(zhuǎn)成類似的數(shù)據(jù)模式。但因?yàn)榇蠹矣兴鶓岩?#xff0c;而且 「核心開發(fā)者」 團(tuán)體也沒(méi)有這個(gè)積極性，我的提議沒(méi)有被采納。

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

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

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

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

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

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

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

其實(shí)，這都不意味著什么，因?yàn)楫?dāng)前的實(shí)現(xiàn)還沒(méi)有到達(dá)效率的極限。

還有幾個(gè) 「未解之謎」：

對(duì)久遠(yuǎn)歷史中的狀態(tài)的默克爾證明還無(wú)法高效生成（對(duì)近期歷史的默克爾證明的生成效率是沒(méi)問(wèn)題的?？梢酝ㄟ^(guò)引入中間哈希值的快照來(lái)緩解（這些數(shù)據(jù)相對(duì)來(lái)說(shuō)也不大）

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

Silkworm

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

但那并不是一個(gè)好時(shí)機(jī)。

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

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

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

更早的 EVM 實(shí)驗(yàn)（使用 EVMC 接口）暴露出了使用跨語(yǔ)言接口的巨大開銷，而 EVMC 的雙重接口又加劇了這一點(diǎn)。

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

未來(lái)

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

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

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

更高的 Gas 上限會(huì)產(chǎn)生（數(shù)據(jù)量）更大的區(qū)塊。這就會(huì)反過(guò)來(lái)產(chǎn)生兩個(gè)問(wèn)題：

• 區(qū)塊傳輸問(wèn)題。這可以通過(guò)預(yù)先共識(shí)來(lái)處理（本質(zhì)上就是犧牲交易時(shí)延來(lái)?yè)Q取交易吞吐量）

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

﹏

﹏

﹏

﹏

推薦閱讀

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

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

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

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

一文讀懂區(qū)塊鏈項(xiàng)目的法律問(wèn)題，通證激勵(lì)、鏈改可行嗎？

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

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

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

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

長(zhǎng)鋏?|?李國(guó)權(quán)?|?螞蟻金服?|?來(lái)學(xué)嘉

總結(jié)

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

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