知道創宇:以太坊主動數據同步簡析

以太坊數據同步是一個複雜的流程,需要節點、數據主體、以太坊P2P通信協議、執行器通力合作才能完成。數據主體如何確定需要同步的數據呢?不同數據又是否需要分類同步呢?一、前言

開門見山,以太坊數據同步是以節點(peer)作為數據載體存放和傳輸主要以Header,Body,Reciept組成的數據主體,通過以太坊p2p通信協議管理數據同步事務,最後交給執行器(主動同步會交給Downloader,被動同步會交給Fetcher)執行最後的數據下載任務。

那麼問起數據主體我們進行同步需要同步哪些數據?不同數據又是否需要分類同步?

知道創宇區塊鏈安全實驗室進行了全面而詳細的分析。

二、數據主體:

進行數據同步首先需要明確我們同步的數據主體由什麼組成,籠統來分有兩類,一類不需要節點發送主動同步請求,節點會在完成數據打包的時候自行向網絡廣播,這一類數據有三種——完整block,區塊hash,和交易Transaction。而我們今天重點探討下一類數據。

第二類數據是需要節點主動發送同步請求隨後其他節點響應才能進行同步的數據,除了第一類數據其他需要同步的數據都屬於第二類,所以可以說他的種類更加繁雜,而其中最重要的也有三種——區塊頭Header,區塊體Body,交易回執Receipt(具體代碼⬇⬇⬇),跟第一類不同這三者可以說都是完整區塊的某一組成部分,這也顯示了主動同步希望節點進行數據同步時範圍自由可控,能夠優先同步必要數據而放棄同步暫時非必要的數據。

⬆Header表示區塊頭,在區塊裡扮演這相當重要的角色,ParentHash會記錄上一個區塊的區塊hash,uncleHash會記錄叔塊hash,coinbase則標識礦工地址。 Root,Txhash,ReceiptHash這三個分別是state trie,tx trie,Receipt.trie三個前綴樹的根節點RLP編碼hash一個用於描述世界狀態,一個用於描述交易,一個用於描述交易回執。 bloom是區塊頭中的布隆過濾器用於快速判斷目標hash是否在某個集合中。 Header中以上數據都是區塊頭用來對區塊以及區塊中重要數據模塊利用hash進行標識的。剩下的數據則各有他用不細贅述。可以看出一個區塊頭其實已經將一個區塊框架基本描述出來了這也為後面談到的數據同步策略埋下了伏筆。

⬆Body就比較簡明了,裡麵包含一組交易對象,和一個叔塊的區塊頭數組。

⬆Receipt是區塊中所有交易對像在執行完成後生成的一個數組,用於記錄交易處理信息。他們會在生成後被逐個插入到Receipt trie中同時也會生成區塊頭中的ReceiptHash。一個交易回執記錄了三部分信息用於交易的管理和標識,第一部分為共識部分,PostState,Status,CumulativeGasUsed,Bloom,Logs只有這五個數據在ReceiptRLP會被encode構成回執hash隨後回執hash會參與共識的校驗,第二部分數據是交易部分,TxHash指的是交易回執所對應的交易哈希,,ContractAddress是當這筆交易是部署新合約時記錄新合約的地址,GasUsed表示該筆交易的Gas使用量,第三部分是區塊部分,他記錄的是BlockHash區塊哈希,BlockNumber當前區塊數,TransactionIndex 該交易在區塊中的序號。對於Receipt在數據同步策略中有著直觀的區別,下文說到的fullSync和fastSync最直觀的區別就在於到底是同步對端的Receipt,還是本地自行生成Receipt。

三、數據載體

數據傳輸載體為peer節點,這個數據載體peer,如果你在源碼裡面去認真尋找你會發現,某些角落裡就能找到一個peer.go.首先我列出有關數據同步模塊我所找到的peer結構。有p2p/peer.go,eth/peer.go ,les/peer.go ,eth/downloader/peer.go。以太坊的網絡也有傳輸層,會話層,表示層和協議層。

previewpreview

那p2p包中的peer扮演了一個底層的節點模型,傳輸層會基於UDP協議發現相鄰peer並維持peer連接,還會基於TCP協議建立peer之間的信息交流通道。會話層Peer管理主要管理的是節點和上層子協議的交互,而NodeTable管理主要管理的是底層基於udp協議構建的節點連接表table。所以p2p這一層的peer節點他需要能獲取和開啟子協議的能力,還需要有ping通其他節點的能力當然還要去接受其他節點消息。這就體現在p2p/peer.go中的3個重要功能模塊,pingLoop,readLoop,startProtocols而這也是peer.run()方法裡的3個函數。

可以看出上面是底層peer結構,下圖則是子協議層的peer結構,不同的子協議層會有不同的peer結構,這也就是為什麼會有eth/peer.go和les/peer.go畢竟不同子協議應用於不同的數據場景。

我們可以看出數據載體有底層peer,和子協議層peer,而進行數據同步需要利用通信協議管理連接兩層peer,由底層實現peer的消息分發,消息的監聽,子協議層peer執行數據的下載和同步,而這兩層之間就需要非常重要的protocolManger進行管理和溝通。

四、數據同步流程

那麼如何啟動protocolManager呢?我們上面介紹了peer結構,他主要是代表遠程其他節點,在以太坊中還有一類同樣是代表了節點的結構Node,他主要代表了本地節點自身會稍微有點區別,而節點想要啟動p2p網絡就要依靠本地Node模塊,其中利用Node.Start()函數開啟了兩個任務,一個是啟動Ethereum Service,其中的Ethereum.start就啟動了protocolmanager;另一個是啟動p2p.Server,新建並刷新K桶,開啟UDP端口監聽,同時監聽TCP端口,處理從遠端節點發來的message。

previewpreview

當protocolManager啟動了之後,他就開始需要連接底層邏輯層peer(p2p)和頂層協議層peer(eth):

當啟動了protocolManager,首先節點會進行初始化,調用NewProtocolManager,初始化的過程中會調用SubProtocol函數向地城p2p.peer獲取一個消息讀寫通道,然後再構建一個消息處理器Handle,Handle,他不僅會接受請求同步的消息,也會接受節點響應的消息,在protocolManger的start方法中他會啟動一個定期同步協程syncer,他會根據消息通知調用fecher或者downloader執行器執行數據同步。

  • 數據同步模式
  1. 主動數據同步指的是本地節點自發的向相鄰節點請求區塊數據,數據入口在eth/downloader/downloader,和eth/handler裡
  2. 被動數據同步指本地節點收到其他節點數據同步消息(Message)而後請求區塊數據,數據入口在eth/fetcher/fetcher.go
  • 主動同步流程我們以主動同步為例,當調用downloader執行器時,他會先調用findAncestor找到本地鍊和遠程鏈的共同祖先,從共同祖先開始同步,他會配置4個fetchers,分別是fetcherHeader,fetcherBodies,fetcherReceipts,ProcessHeaders最後根據同步模式調用收到processFullSyncContent 和processFastSyncContent最後調用spawnSync執行同步。

previewpreview

以上為同步過程的源碼,從源碼裡可以看出主要的下載任務是集中在他構造的可拓展fetchers裡,他是一個fetcher任務隊列。而根據不同的數據同步策略他的fetcher任務隊列不僅構造不同,fetcher之間的協作流程也不盡相同。

五、數據同步策略

fetcher任務隊列的作用概括起來就是在進行,數據填充,數據組裝,和最後的數據插入。而其中填充什麼樣的數據,那些數據需要組裝,什麼時候插入數據,均由一個重要的數據結構mode進行標識,他代表了數據同步策略,主要分為三種。

  1. lightSync:輕節點同步,數據填充的時候只填充區塊頭數據,不需要進行數據組裝,調用insertHeaderchain直接插入區塊頭。
  2. fullSync:全節點同步,數據填充的時候需要填充區塊頭Header,區塊體Body,但不填充交易回執Receipt,將數據組裝到結果集Result,之後調用importBlockResults將結果集內數據插入到主鏈,和lightSync區別在於輕節點同步沒有區塊體,所以他不會執行和驗證交易而fullSync全節點同步會在插入數據的同時執行交易並驗證這也是他為什麼同步速度慢的原因,之後會自行生成交易回執Receipt,所以他在填充組裝的時候不需要Receipt參與。
  3. fastSync:快速同步,數據填充的時候會填充Header,Body,同時也會填充Receipt,然後組裝3個數據,執行數據插入,而在執行數據插入的時候和fullSync,lightSync完全不同,他調用的commitFastSyncData這個函數和fullSync全節點同步調用的importBlockResults不一樣他不會執行交易而只是提交同步數據,所以他為了保證安全加了一步驗證獲取來的交易回執。而這也才是快速同步的一部分,快速同步為了保證數據的安全性古老的區塊會使用上述方法同步,對於時間上來說比較新的區塊會使用fullSync的同步模式進行同步。用而言之就是fastSync會快速同步一大部分而一小部分還是會按照fullSync的同步模式同步。

六、結語

以太坊數據同步非常複雜,他涵蓋了其網絡架構,通信協議管理,數據傳輸通道的相互配合,數據同步策略的安排,以及加速數據同步速率的算法。其中還有眾多細節和邏輯關係。而數據同步是區塊鏈節點和外界通信的基石他還有更多的架構彩蛋令人拍案叫絕。期待後續文章和大家分享。

展開全文打開碳鏈價值APP 查看更多精彩資訊

Total
0
Shares
Related Posts