以太坊主流客戶端：Geth整體架構

這篇文章是Geth 原始碼系列的第一篇，透過這個系列，我們將建立一個研究Geth 實現的框架，開發者可以根據這個框架深入自己感興趣的部分研究。這個系列共有六篇文章，在第一篇文章中，將研究執行層客戶端Geth 的設計架構以及Geth 節點的啟動流程。 Geth 程式碼更新的速度很快，後續看到的程式碼可能會有所不同，但整體的設計大致一致，新的程式碼也可以用同樣的思路閱讀。

01\以太坊客戶端

以太坊在進行The Merge 升級之前，以太坊只有一個客戶端，這個客戶端及負責交易的執行，也會負責區塊鏈的共識，保證區塊鏈以一定的順序產生新的區塊。在The Merge 升級之後，以太坊用戶端分為了執行層和共識層，執行層負責交易的執行、狀態和資料的維護，共識層則負責共識功能的實現，執行層和共識層透過API 來通訊。執行層和共識層有各自的規範，客戶端可以使用不同的語言來實現，但是要符合對應的規範，其中Geth 就是執行層客戶端的一種實現。當前主流的執行層和共識層客戶端有以下實現：

執行層

• Geth：由以太坊基金會直接資助的團隊維護，使用Go 語言開發，是公認的最穩定、久經考驗的客戶端
• Nethermind：由Nethermind 團隊開發和維護，使用C# 語言開發，早期由以太坊基金會和Gitcoin 社群資助
• Besu：最初由ConsenSys 的PegaSys 團隊開發，現為Hyperledger 社區項目，使用Java 語言開發
• Erigon：由Erigon 團隊開發和維護，由以太坊基金會、BNB Chain 資助。 2017 年從Geth 分叉而來，目標是提升同步速度與磁碟效率
• Reth：由Paradigm 主導開發，開發語言是Rust，強調模組化和高效能，目前已經趨近成熟，可以在生產環境使用

共識層

• Prysm：由Prysmatic Labs 維護，是以太坊最早的共識層客戶端之一，以Go 語言開發，專注於可用性和安全性，早期由以太坊基金會資助
• Lighthouse：由Sigma Prime 團隊維護，使用Rust 語言開發，主打高效能和企業級安全，適用於高負載場景
• Teku：早起由ConsenSys 的PegaSys 團隊開發，後來成為Hyperledger Besu 社群的一部分，用Java 語言開發
• Nimbus：由Status Network 團隊開發和維護，使用Nim 語言開發，專為資源受限設備（如手機、物聯網設備）優化，目標是在嵌入式系統中實現輕量化運行

02\執行層簡介

可以將以太坊執行層視為一個由交易驅動的狀態機，執行層最基礎的功能就是透過EVM 執行交易來更新狀態資料。除了交易執行之外，還有保存並驗證區塊和狀態數據，運行p2p 網路並維護交易池等功能。

交易由使用者（或程式）按照以太坊執行層規範定義的格式生成，使用者需要對交易進行簽名，如果交易是合法的（Nonce 連續、簽名正確、gas fee 足夠、業務邏輯正確），那麼交易最終就會被EVM 執行，從而更新以太坊網路的狀態。這裡的狀態是指資料結構、資料和資料庫的集合，包括外部帳戶地址、合約地址、地址餘額以及代碼和資料。

執行層負責執行交易以及維護交易執行之後的狀態，共識層負責選擇哪些交易來執行。 EVM 則是這個狀態機中的狀態轉換函數，函數的輸入會來自多個地方，有可能來自共識層提供的最新區塊信息，也有可能來自p2p 網路下載的區塊。

共識層和執行層透過Engine API 來進行通信，這是執行層和共識層之間唯一的通訊方式。如果共識層拿到了出塊權，就會透過Engine API 讓執行層產出新的區塊，如果沒有拿到出塊權，就會同步最新的區塊讓執行層驗證和執行，從而與整個以太坊網路保持共識。

執行層從邏輯上可以分為6 個部分：

• EVM：負責執行交易，交易執行也是修改狀態數的唯一方式
• 儲存：負責state 以及區塊等資料的存儲
• 交易池：用於使用者提交的交易，暫時存儲，並且會透過p2p 網路在不同節點之間傳播
• p2p 網路：用於發現節點、同步交易、下載區塊等等功能
• RPC 服務：提供存取節點的能力，例如使用者向節點發送交易，共識層和執行層之間的交互
• BlockChain：負責管理以太坊的區塊鏈數據

下圖展示了執行層的關鍵流程，以及每個部分的職能：

對於執行層（這裡暫時只討論Full Node），有三個關鍵流程：

• 如果是新加入以太坊的節點，需要透過p2p 網路從其他的節點同步區塊和狀態數據，如果是Full Sync，會從創世區塊開始逐個下載區塊，驗證區塊並透過EVM 重建狀態資料庫，如果是Snap Sync，則跳過全部區塊驗證的過程，直接下載最新checkpoint 的狀態資料和以後的區塊數據
• 如果是已經同步到最新狀態的節點，那麼就會持續透過Engine API 從共識層獲取到當前最新產出的區塊，並驗證區塊，然後透過EVM 執行區塊中所有的交易來更新狀態資料庫，並將區塊寫入本地鏈
• 如果是已經同步到最新狀態，並且共識層拿到了出塊權的節點，就會透過Engine API 驅動執行層產出最新的區塊，執行層從交易池獲取交易並執行，然後組裝成區塊通過Engine API 傳遞給共識層，由共識層將區塊廣播到共識層p2p 網路

03\原始碼結構

go-ethereum 的程式碼結構很龐大，但其中許多程式碼屬於輔助程式碼和單元測試，在研究Geth 原始碼時，只需要專注於協定的核心實現，各個模組功能如下。需專注於core、eth、ethdb、node、p2p、rlp、trie triedb 等模組：

• accounts：管理以太坊帳戶，包括公私鑰對的產生、簽章驗證、地址派生等
• beacon：處理與以太坊信標鏈（Beacon Chain）的交互邏輯，支持權益證明（PoS）共識的合併（The Merge）後功能
• build：建置腳本和編譯配置（如Dockerfile、跨平台編譯支援）
• cmd：命令列工具入口，包含多個子命令
• common：通用工具類，如位元組處理、位址格式轉換、數學函數
• consensus：定義consensus engine ，包括先前的工作量證明（Ethash）和單機權益證明（Clique）以及Beacon engine 等
• console：提供互動式JavaScript 控制台，讓使用者透過命令列直接與以太坊節點互動（如呼叫Web3 API、管理帳戶、查詢區塊鏈資料）
• core：區塊鏈核心邏輯，處理區塊/交易的生命週期管理、狀態機、Gas運算等
• crypto：加密演算法實現，包括橢圓曲線（secp256k1）、雜湊（Keccak-256）、簽章驗證
• docs：文件（如設計規格、API 說明）
• eth：以太坊網路協定的完整實現，包括節點服務、區塊同步（如快速同步、歸檔模式）、交易廣播等
• ethclient：實現以太坊客戶端庫，封裝JSON-RPC 接口，供Go 開發者與以太坊節點交互（如查詢區塊、發送交易、部署合約）
• ethdb：資料庫抽象層，支援LevelDB、Pebble、記憶體資料庫等，儲存區塊鏈資料（區塊、狀態、交易）
• ethstats：收集並回報節點運作狀態到統計服務，用於監控網路健康狀態
• event：實作事件訂閱與發布機制，支援節點內部模組間的非同步通訊（如新區塊到達、交易池更新）
• graphql：提供GraphQL 接口，支援複雜查詢（替代部分JSON-RPC 功能）
• internal：內部工具或限制外部存取的程式碼
• log：日誌系統，支援分級日誌輸出、上下文日誌記錄
• mertrics：性能指標收集（Prometheus 支援）
• miner：挖礦相關邏輯，產生新區塊並打包交易（PoW 場景下）
• node：節點服務管理，整合p2p、RPC、資料庫等模組的啟動與配置
• p2p：點對點網路協定實現，支援節點發現、資料傳輸、加密通訊
• params：定義乙太坊網路參數（主網、測試網、創世區塊配置）
• rlp：實作以太坊專用的資料序列化協定RLP（Recursive Length Prefix），用於編碼/解碼區塊、交易等資料結構
• rpc：實作JSON-RPC 和IPC 接口，供外部程式與節點交互
• signer：交易簽章管理（硬體錢包整合）
• tests：整合測試和狀態測試，驗證協定相容性
• trie triedb：默克爾帕特里夏樹（Merkle Patricia Trie）的實現，用於高效存儲和管理帳戶狀態、合約存儲

04\執行層模組劃分

外部存取Geth 節點有兩種形式，一種是透過RPC，另一種是透過Console。 RPC 適合開放給外部的使用者來使用，Console 適合節點的管理者使用。但無論是透過RPC 還是Console，都是使用內部已經封裝好的能力，這些能力透過分層的方式來建構。

最外層就是API 用於外部存取節點的各項能力，Engine API 用於執行層和共識層之間的通信，Eth API 用於外部用戶或程式發送交易，獲取區塊信息，Net API 用於獲取p2p 網路的狀態等等。 例如用戶透過API 發送了一個交易，那麼這個交易最終會被提交到交易池中，透過交易池來管理，再例如用戶需要取得一個區塊數據，那麼就需要呼叫資料庫的能力去取得對應的區塊。

在API 的下一層就核心功能的實現，包括交易池、交易包裝、產出區塊、區塊和狀態的同步等等。這些功能再往下需要依賴更底層的能力，例如交易池、區塊和狀態的同步需要依賴p2p 網路的能力，區塊的產生以及從其他節點同步過來的區塊需要被驗證才能寫入到本地的資料庫，這些就需要依賴EVM 和資料儲存的能力。

執行層核心資料結構

Ethereum

在eth/backend.go 中的Ethereum 結構是整個以太坊協議的抽象，基本上包括了以太坊中的主要組件，但EVM 是一個例外，它會在每次處理交易的時候實例化，不需要隨著整個節點初始化，下文中的Ethereum 都是指這個結構體：

type Ethereum struct { // 以太坊配置，包括鏈配置config *ethconfig.Config // 交易池，用戶的交易提交之後先到交易池txPool *txpool.TxPool // 用於追蹤和管理本地交易（local transactions） localTxTracker *locals.TxTracker // 區塊鏈結構.是以太坊節點的網路層核心元件，負責處理所有與其他節點的通信，包括區塊同步、交易廣播和接收，以及管理對等節點連接handler *handler // 負責節點發現和節點來源管理discmix *enode.FairMix // 負責區塊鏈資料的持久化儲存和訂閱管理使用者帳戶和金鑰accountManager *accounts.Manager // 管理日誌過濾器和區塊過濾器filterMaps *filtermaps.FilterMaps // 用於安全關閉filterMaps 的通道，確保在節點關閉時正確清理資源closeFilterMaps chan 回 *struct} // 為RPC API 提供後端支援APIBackend節點接受的最低gas價格gasPrice *big.Int // 網路ID networkID uint64 // 提供網路相關的RPC 服務，允許透過RPC 查詢網路狀態netRPCService *ethapi.NetAPI // 管理P2P網路連接，處理節點發現並連接建立並提供底層網路可變的功能並發出存取權/追蹤節點是否正常關閉，在異常關閉後幫助恢復shutdownTracker *shutdowncheck.ShutdownTracker }

Node

在node/node.go 中的Node 是另一個核心的資料結構，它作為一個容器，負責管理和協調各種服務的運作。在下面的結構中，需要注意一下lifecycles 字段，Lifecycle 用來管理內部功能的生命週期。例如上面的Ethereum 抽象就需要依賴Node 才能啟動，並且在lifecycles 中註冊。這樣可以將具體的功能與節點的抽象分離，提升整個架構的擴充性，這個Node 需要與devp2p 中的Node 區分開。

type Node struct { eventmux *event.TypeMux config *Config // 帳號管理器，負責管理錢包與帳號accman *accounts.Manager log log.Logger keyDir string keyDirTemp bool dirLock *flock.Flock stop chan structef} // p7p 網頁實例{psyp.追蹤節點生命週期狀態（初始化、運行中、已關閉） state int lock sync.Mutex // 所有註冊的後端、服務和輔助服務lifecycles []Lifecycle // 目前提供的API 清單 rpcAPIs []rpc.API // 為RPC 提供的不同存取方式http *httpServer rpcAPIs []rpc.API // 為RPC 提供的不同存取方式http *rpc.Server databases map[*closeTrackingDB]struct{} }

如果以一個抽象的維度來看以太坊的執行層，以太坊作為一台世界計算機，需要包括三個部分，網絡、計算和存儲，那麼以太坊執行層中與這三個部分相對應的組件是：

• 網路：devp2p
• 計算：EVM
• 儲存：ethdb

devp2p

以太坊本質還是一個分散式系統，每個節點透過p2p 網路與其他節點相連。以太坊中的p2p 網路協定的實現就是devp2p。

devp2p 有兩個核心功能，一個是節點發現，讓節點在接入網路時能夠與其他節點建立聯繫；另一個是資料傳輸服務，在與其他節點建立聯繫之後，就可以想換交換資料。

在p2p/enode/node.go 中的Node 結構代表了p2p 網路中一個節點，其中enr.Record 結構中儲存了節點詳細資訊的鍵值對，包括身分識別資訊（節點身分所使用的簽章演算法、公鑰）、網路資訊（IP 位址，連接埠號碼）、支援的協定資訊（例如支援eth/68 和的方式編碼，具體的規範在eip-778 中定義：

type Node struct { // 節點記錄，包含節點的各種屬性r enr.Record // 節點的唯一標識符，32位元組長度id ID // hostname 追蹤節點的DNS名稱hostname string // 節點的IP位址ip netip.Addr // UDP 埠[]byte // RLP 編碼後的記錄raw []byte // 所有鍵值對的排序列表pairs []pair }

在p2p/discover/table.go 中的Table 結構是devp2p 實作節點發現協定的核心資料結構，它實作了類似Kademlia 的分散式雜湊表，用於維護和管理網路中的節點資訊。

printf("type ？週期性的處理網路中的各種事件refreshReq chan chan struct{} revalResponseCh chan revalidationResponse addNodeCh chan addNodeOp addNodeHandled chan bool trackRequestCh chan trackRequestOp initDone chanchan {p} close> 假} 識別字詞的定義。 func(*bucket, *tableNode) nodeRemovedHook func(*bucket, *tableNode)} world!");

ethdb

ethdb 完成以太坊資料儲存的抽象，提供統一的儲存接口，底層具體的資料庫可以是leveldb，也可以是pebble 或其他的資料庫。可以有很多的擴展，只要在介面層面保持統一。

有些資料（如區塊資料）可以透過ethdb 介面直接對底層資料庫進行讀寫，其他的資料儲存介面都是建立的ethdb 的基礎上，例如資料庫有大部分的資料是狀態數據，這些資料會被組織成MPT 結構，在Geth 中對應的實作是trie，在節點運行的過程中，trie 資料會產生很多中間狀態，這些資料不能直接讀寫節點，來管理這些資料和中間狀態，最後才透過ethdb 來持久化。

在ethdb/database.go 中定義底層資料庫的讀寫能力的接口，但沒有包括具體的實現，具體的實現將由不同的資料庫本身來實現。例如leveldb 或pebble 資料庫。在Database 中定義了兩層數據讀寫的接口，其中KeyValueStore 接口用於存儲活躍的、可能頻繁變化的數據，如最新的區塊、狀態等。 AncientStore 則用於處理歷史區塊數據，這些數據一旦寫入就很少改變。

// 資料庫的頂層介面type Database interface { KeyValueStore AncientStore}// KV 資料的讀寫介面type Database interface { KeyValueStore AncientStore}// KV 資料的讀寫介面type KeyValueStore interface { KeyValueReader KeyValueWriter KeyValueStater KeyValueRangeDeleter Batcher Iteratee 介面io.Closer}

EVM

EVM 是以太坊這個狀態機的狀態轉換函數，所有狀態資料的更新都只能透過EVM 來進行，p2p 網路可以接受到交易和區塊訊息，這些資訊被EVM 處理之後會成為狀態資料庫的一部分。 EVM 屏蔽了底層硬體的不同，讓程式在不同平台的EVM 上執行都能得到一致的結果。這是一種很成熟的設計方式，Java 語言中JVM 也是類似的設計。

EVM 的實作有三個主要的元件，core/vm/evm.go 中的EVM 結構體定義了EVM 的整體結構及依賴，包括執行上下文，狀態資料庫依賴等等；core/EV/interpreter.go 中的EVMInterpreter 結構體定義了解譯器的實作，負責執行EVM 字節碼；結構體封裝合約呼叫的特定參數，包括呼叫者、合約程式碼、輸入等等，並且在core/vm/opcodes.go 中定義了目前所有的操作碼：

// EVMtype EVM struct { // 區塊上下文，包含區塊相關資訊Context BlockContext // 交易上下文，包含交易相關資訊TxContext // 狀態資料庫，包含區塊相關資訊Context BlockContext // 交易上下文，包含交易相關資訊TxContext // 狀態資料庫，用於存取和修改帳戶狀態StateDB StateDB // 目前呼叫深度depth int // 鏈配置參數chainConfig *params.ChainConfig chainRuvRupter中止執行的標誌Keccak256雜湊器實例，在操作碼間共用hasher crypto.KeccakState // Keccak256雜湊結果緩衝區hasherBuf common.Hash // 是否為唯讀模式，唯讀模式下不允許狀態修改readOnly bool // 上一次CALL的回傳資料，用於後續重用位址common.Address jumpdests map[common.Hash]bitvec analysis bitvec // 合約字節碼Code []byte // 程式碼雜湊CodeHash common.Hash // 呼叫輸入Input []byte // 是否為合約部署IsDeployment bool // 是否可用系統為系統的數量。 *uint256.Int }

其他模組實現

執行層的功能透過分層的方式來實現，其他的模組和功能都是在這三個核心組件的基礎之上建構起來的。這裡介紹一下幾個核心的模組。

在eth/protocols 下有當前以太坊的p2p網路子協議的實現。有eth/68 和snap 子協議，這個些子協議都是在devp2p 上建構的。

eth/68 是以太坊的核心協議，協議名稱就是eth，68 是它的版本號，然後在這個協議的基礎之上又實現了交易池（TxPool）、區塊同步（Downloader）和交易同步（Fetcher）等功能。 snap 協定用於新節點加入網路時快速同步區塊和狀態資料的，可以大幅減少新節點啟動的時間。

ethdb 提供了底層資料庫的讀寫能力，由於以太坊協議中有很多複雜的資料結構，直接透過ethdb 無法實現這些資料的管理，所以在ethdb 上又實現了rawdb 和statedb 來分別管理區塊和狀態資料。

EVM 則貫穿所有的主流程，無論是區塊建置還是區塊驗證，都需要用EVM 執行交易。

05\Geth 節點啟動流程

Geth 的啟動會分為兩個階段，第一階段會初始化節點所需啟動的元件和資源，第二節點會正式啟動節點，然後對外服務。

節點初始化

在啟動一個geth 節點時，會涉及到以下的程式碼：

各模組的初始化如下：

• cmd/geth/main.go：geth 節點啟動入口
• cmd/geth/config.go（makeFullNode）：載入配置，初始化節點

• node/node.go：初始化以太坊節點的核心容器

1. node.rpcstack.go：初始化RPC 模組
2. accounts.manager.go：初始化accountManager

• eth/backend.go：初始化Ethereum 實例

1. node/node.go OpenDatabaseWithFreezer：初始化chaindb
2. eth/ethconfig/config.go：初始化共識引擎實例（這裡的共識引擎並不真正參與共識，只是會驗證共識層的結果，以及處理validator 的提款請求）
3. core/blockchain.go：初始化blockchain
4. core/filterMaps.go：初始化filtermaps
5. core/txpool/blobpool/blobpool.go：初始化blob 交易池
6. core/txpool/legacypool/legacypool.go：初始化普通交易池
7. cord/txpool/locals/tx_tracker.go：本地交易追蹤（需要配置開啟本地交易追踪，本地交易會被更高優先級處理）
8. eth/handler.go：初始化協定的Handler 實例
9. miner/miner.go：實例化交易打包的模組（原挖礦模組）
10. eth/api_backend.go：實例化RPC 服務
11. eth/gasprice/gasprice.go：實例化gas 價格查詢服務
12. internal/ethapi/api.go：實例化P2P 網路RPC API
13. node/node.go(RegisterAPIs)：註冊RPC API
14. node/node.go(RegisterProtocols)：註冊p2p 的Ptotocols
15. node/node.go(RegisterLifecycle)：註冊各個組件的生命週期

• cmd/utils/flags.go(RegisterFilterAPI)：註冊Filter RPC API
• cmd/utils/flags.go(RegisterGraphQLService)：註冊GraphQL RPC API（如果配置了的話）
• cmd/utils/flags.go(RegisterEthStatsService)：註冊EthStats RPC API（如果配置了的話）
• eth/catalyst/api.go：註冊Engine API

節點的初始化會在cmd/geth/config.go 中的makeFullNode 中完成，重點會初始化以下三個模組

在第一步驟會初始化node/node.go 中的Node 結構，就是整個節點容器，所有的功能都需要在這個容器中運行，第二步會初始化Ethereum 結構，其中包括以太坊各種核心功能的實現，Etherereum 也需要註冊到Node 中，第三步就是註冊Engine API 到Node 中。

其中Node 初始化就是創建了一個Node 實例，然後初始化p2p server、帳號管理以及http 等暴露給外部的協定連接埠。

Ethereum 的初始化就會複雜很多，大多數的核心功能都是在這裡初始化。首先會初始化化ethdb，並從儲存中載入鏈配置，然後建立共識引擎，這裡的共識引擎不會執行共識操作，而只是會對共識層回傳的結果進行驗證，如果共識層發生了提款請求，也會在這裡完成實際的提款操作。然後再初始化Block Chain 結構和交易池。

這些都完成之後就會初始化handler，handler 是所有p2p 網路請求的處理入口，包括交易同步、區塊下載等等，是以太坊實現去中心化運作的關鍵元件。在這些都完成之後，就會將一些在devp2p 基礎之上實現的子協議，例如eth/68、snap 等註冊到Node 容器中，最後Ethereum 會作為一個lifecycle 註冊到Node 容器中，Ethereum 初始化完成。

最後Engine API 的初始化相對簡單，只是將Engine API 註冊到Node 中。到這裡，節點初始化就全部完成了。

節點啟動

在完成節點的初始化之後，就需要啟動節點了，節點啟動的流程相對簡單，只需要將已經註冊的RPC 服務和Lifecycle 全部啟動，那麼整個節點就可以向外部提供服務了。

06\總結

在深入理解以太坊執行層的實現之前，需要對以太坊有一個整體的認識，可以將以太坊整體看作是一個交易驅動的狀態機，執行層負責交易的執行和狀態的變更，共識層則負責驅動執行層運行，包括讓執行層產出區塊、決定交易的順序、為區塊投票、以及讓區塊獲得最終性。由於這個狀態機是去中心化的，所以需要透過p2p 網路與其他的節點通信，共同維護狀態資料的一致性。

在執行層不負責決定交易的順序，只負責執行交易並記錄交易執行之後的狀態變化。這裡的記錄有兩種形式，一種是以區塊的方式將所有的狀態變化都記錄下來，另一種是在資料庫中記錄當前的狀態。同時執行層也是交易的入口，透過交易池來儲存還沒有被打包進區塊的交易。如果其他的節點需要取得區塊、狀態和交易數據，執行層就會透過p2p 網路將這些資訊傳送出去。

對於執行層，有三個核心模組：運算、儲存和網路。計算對應EVM 的實現，儲存則對應了ethdb 的實現，網路對了devp2p 的實現。有了這樣的整體認識之後，就可以深入去理解每一個子模組，而不會迷失在具體的細節中。

07\Ref

[1]https://ethereum.org/zh/what-is-ethereum/

[2]https://epf.wiki/#/wiki/protocol/architecture

[3]https://clientdiversity.org/#distribution

[4]https://github.com/ethereum/devp2p

[5]https://github.com/ethereum/execution-specs

[6]https://github.com/ethereum/consensus-specs

·END·

內容| Ray

編輯 排版| 環環

設計| Daisy