ethpending

A. 以太坊源碼分析--p2p節點發現

節點發現功能主要涉及 Server Table udp 這幾個數據結構，它們有獨自的事件響應循環，節點發現功能便是它們互相協作完成的。其中，每個以太坊客戶端啟動後都會在本地運行一個 Server ，並將網路拓撲中相鄰的節點視為 Node ，而 Table 是 Node 的容器， udp 則是負責維持底層的連接。下面重點描述它們中重要的欄位和事件循環處理的關鍵部分。

PrivateKey - 本節點的私鑰，用於與其他節點建立時的握手協商
Protocols - 支持的所有上層協議
StaticNodes - 預設的靜態 Peer ，節點啟動時會首先去向它們發起連接，建立鄰居關系
newTransport - 下層傳輸層實現，定義握手過程中的數據加密解密方式，默認的傳輸層實現是用 newRLPX() 創建的 rlpx ，這不是本文的重點
ntab - 典型實現是 Table ，所有 peer 以 Node 的形式存放在 Table
ourHandshake - 與其他節點建立連接時的握手信息，包含本地節點的版本號以及支持的上層協議
addpeer － 連接握手完成後，連接過程通過這個通道通知 Server

Server 的監聽循環，啟動底層監聽socket，當收到連接請求時，Accept後調用 setupConn() 開始連接建立過程

Server的主要事件處理和功能實現循環

Node 唯一表示網路上的一個節點

IP - IP地址
UDP/TCP - 連接使用的UDP/TCP埠號
ID - 以太坊網路中唯一標識一個節點，本質上是一個橢圓曲線公鑰(PublicKey)，與 Server 的 PrivateKey 對應。一個節點的IP地址不一定是固定的，但ID是唯一的。
sha - 用於節點間的距離計算

Table 主要用來管理與本節點與其他節點的連接的建立更新刪除

bucket - 所有 peer 按與本節點的距離遠近放在不同的桶(bucket)中，詳見之後的 節點維護
refreshReq - 更新 Table 請求通道

Table 的主要事件循環，主要負責控制 refresh 和 revalidate 過程。
refresh.C - 定時(30s)啟動Peer刷新過程的定時器
refreshReq - 接收其他線程投遞到 Table 的 刷新Peer連接 的通知，當收到該通知時啟動更新，詳見之後的 更新鄰居關系
revalidate.C - 定時重新檢查以連接節點的有效性的定時器，詳見之後的 探活檢測

udp 負責節點間通信的底層消息控制，是 Table 運行的 Kademlia 協議的底層組件

conn - 底層監聽埠的連接
addpending － udp 用來接收 pending 的channel。使用場景為：當我們向其他節點發送數據包後(packet)後可能會期待收到它的回復，pending用來記錄一次這種還沒有到來的回復。舉個例子，當我們發送ping包時，總是期待對方回復pong包。這時就可以將構造一個pending結構，其中包含期待接收的pong包的信息以及對應的callback函數，將這個pengding投遞到udp的這個channel。 udp 在收到匹配的pong後，執行預設的callback。
gotreply - udp 用來接收其他節點回復的通道，配合上面的addpending，收到回復後，遍歷已有的pending鏈表，看是否有匹配的pending。
Table - 和 Server 中的ntab是同一個 Table

udp 的處理循環，負責控制消息的向上遞交和收發控制

udp 的底層接受數據包循環，負責接收其他節點的 packet

以太坊使用 Kademlia 分布式路由存儲協議來進行網路拓撲維護，了解該協議建議先閱讀 易懂分布式 。更權威的資料可以查看 wiki 。總的來說該協議：

源碼中由 Table 結構保存所有 bucket ， bucket 結構如下

節點可以在 entries 和 replacements 互相轉化，一個 entries 節點如果 Validate 失敗，那麼它會被原本將一個原本在 replacements 數組的節點替換。

有效性檢測就是利用 ping 消息進行探活操作。 Table.loop() 啟動了一個定時器（0~10s），定期隨機選擇一個bucket，向其 entries 中末尾的節點發送 ping 消息，如果對方回應了 pong ，則探活成功。

Table.loop() 會定期（定時器超時）或不定期（收到refreshReq）地進行更新鄰居關系（發現新鄰居），兩者都調用 doRefresh() 方法，該方法對在網路上查找離自身和三個隨機節點最近的若干個節點。

Table 的 lookup() 方法用來實現節點查找目標節點，它的實現就是 Kademlia 協議，通過節點間的接力，一步一步接近目標。

當一個節點啟動後，它會首先向配置的靜態節點發起連接，發起連接的過程稱為 Dial ，源碼中通過創建 dialTask 跟蹤這個過程

dialTask表示一次向其他節點主動發起連接的任務

在 Server 啟動時，會調用 newDialState() 根據預配置的 StaticNodes 初始化一批 dialTask ， 並在 Server.run() 方法中，啟動這些這些任務。

Dial 過程需要知道目標節點( dest )的IP地址，如果不知道的話，就要先使用 recolve() 解析出目標的IP地址，怎麼解析？就是先要用藉助 Kademlia 協議在網路中查找目標節點。

當得到目標節點的IP後，下一步便是建立連接，這是通過 dialTask.dial() 建立連接

連接建立的握手過程分為兩個階段，在在 SetupConn() 中實現
第一階段為 ECDH密鑰建立 ：

第二階段為協議握手,互相交換支持的上層協議

如果兩次握手都通過，dialTask將向 Server 的 addpeer 通道發送 peer 的信息

B. 以太坊多節點私有鏈部署

假設兩台電腦A和B
要求：
1、兩台電腦要在一個網路中，能ping通
2、兩個節點使用相同的創世區塊文件
3、禁用ipc;同時使用參數--nodiscover
4、networkid要相同，埠號可以不同

1.4 搭建私有鏈
1.4.1 創建目錄和genesis.json文件
創建私有鏈根目錄./testnet
創建數據存儲目錄./testnet/data0
創建創世區塊配置文件./testnet/genesis.json

1.4.2 初始化操作
cd ./eth_test
geth --datadir data0 init genesis.json

1.4.3 啟動私有節點

1.4.4 創建賬號
personal.newAccount()
1.4.5 查看賬號
eth.accounts
1.4.6 查看賬號余額
eth.getBalance(eth.accounts[0])
1.4.7 啟動&停止挖礦
啟動挖礦：
miner.start(1)
其中 start 的參數表示挖礦使用的線程數。第一次啟動挖礦會先生成挖礦所需的 DAG 文件，這個過程有點慢，等進度達到 100% 後，就會開始挖礦，此時屏幕會被挖礦信息刷屏。
停止挖礦，在 console 中輸入：
miner.stop()
挖到一個區塊會獎勵5個以太幣，挖礦所得的獎勵會進入礦工的賬戶，這個賬戶叫做 coinbase，默認情況下 coinbase 是本地賬戶中的第一個賬戶，可以通過 miner.setEtherbase() 將其他賬戶設置成 coinbase。

1.4.8 轉賬
目前，賬戶 0 已經挖到了 3 個塊的獎勵，賬戶 1 的余額還是0：

我們要從賬戶 0 向賬戶 1 轉賬，所以要先解鎖賬戶 0，才能發起交易：

發送交易，賬戶 0 -> 賬戶 1：

需要輸入密碼 123456

此時如果沒有挖礦，用 txpool.status 命令可以看到本地交易池中有一個待確認的交易，可以使用 eth.getBlock("pending", true).transactions 查看當前待確認交易。

使用 miner.start() 命令開始挖礦：
miner.start(1);admin.sleepBlocks(1);miner.stop();

新區塊挖出後，挖礦結束，查看賬戶 1 的余額，已經收到了賬戶 0 的以太幣：
web3.fromWei(eth.getBalance(eth.accounts[1]),'ether')

用同樣的genesis.json初始化操作
cd ./eth_test
geth --datadir data1 init genesis.json

啟動私有節點一,修改 rpcport 和port

可以通過 admin.addPeer() 方法連接到其他節點，兩個節點要要指定相同的 chainID。

假設有兩個節點：節點一和節點二，chainID 都是 1024，通過下面的步驟就可以從節點二連接到節點一。

首先要知道節點一的 enode 信息，在節點一的 JavaScript console 中執行下面的命令查看 enode 信息：

admin.nodeInfo.enode
" enode://@[::]:30303 "

然後在節點二的 JavaScript console 中執行 admin.addPeer()，就可以連接到節點一：

addPeer() 的參數就是節點一的 enode 信息，注意要把 enode 中的 [::] 替換成節點一的 IP 地址。連接成功後，節點一就會開始同步節點二的區塊，同步完成後，任意一個節點開始挖礦，另一個節點會自動同步區塊，向任意一個節點發送交易，另一個節點也會收到該筆交易。

通過 admin.peers 可以查看連接到的其他節點信息，通過 net.peerCount 可以查看已連接到的節點數量。

除了上面的方法，也可以在啟動節點的時候指定 --bootnodes 選項連接到其他節點。 bootnode 是一個輕量級的引導節點，方便聯盟鏈的搭建 下一節講 通過 bootnode 自動找到節點

參考： https://cloud.tencent.com/developer/article/1332424

C. Miner 流程

以太坊的礦工出塊的流程，不同版本有過變更，下面基於1.7.3版本和1.8.4版本來分享

channel： 用於1發1收

發送 ：sampleChan<-

接收 ： <-sampleChan 

Feed：用於1發多收，參考chainHeadCh

接收者注冊 ：Subscribe（sampleChan）

發送 ：send, 發送的地方不太好找，需要通過send和event/channel類型查找，例如miner中主要涉及到的就是 PostChainEvents

接收 ：<-sampleChan

數據結構：

可以理解為操作間（eth）中有了礦（tx），那麼礦主（miner）安排工人（worker）挖礦（seal）。結構體定義如下：

Type Miner struct {  -- - 理解為礦主

    mux        *event.TypeMux

    worker     *worker    ---- 理解為幹活的工人

    coinbase    common.Address

    eth            Backend    - --- 理解為操作間

    engine      consensus.Engine    ---- 理解為挖礦的工具

    exitCh        chan struct {}

    canStart        int32 //canstart indicates whether we can start the mining operation

    shouldStart  int32 //shouldstart indicates whether we should start after sync

}

 流程圖如下：

1.  節點啟動： backend.new->miner.new->worker.new: 調用commitNewWork，裡面使用push把work傳遞給cpuAgent， 之後在geth命令行敲miner.start()後->miner.start->worker.start->cpuAgent.start,調用Seal，計算nonce值，再發送 recv 消息，通知 worker . wait ，在收到之後將塊打包插入到區塊鏈，之後調用PostChainEvents，發送消息chainHeadCh， Worker.update 在收到消息後，重新調用 commitNewWor k，形成一個循環。

 2.  創世塊： 調用geth的init命令觸發調用initGenesis->SetupGenesisBlock, 裡面具體強調一下time是使用的genesisBlock.json中的值，一般都是0.

  3.  正常情況： worker . wait ，在收到之後將塊打包插入到區塊鏈，之後調用PostChainEvents，發送消息chainHeadCh， Worker.update 在收到消息後，重新調用 commitNewWor k，形成一個循環。

Miner .new: 在backend new的時候調用，即在節點啟動的時候調用。

Miner . update ：在節點啟動的時候調用，用於監控是否有塊同步，如果有則停止挖礦，如果沒有啟動挖礦，這個在POW這種競爭性出塊的環境中需要。

Worker .new: 在miner.new的時候調用，記載節點啟動的時候調用 

Worker.update: 節點啟動的時候調用，如果是非全節點的話用於監控接受交易transaction，關鍵函數 commitTransactions ，還用於調度在收到 chainHeadCh 的消息後，觸發 commitNewWork

其中 commitNewWork :  用於將pending的tx輸入到系統，計算trie等等操作，生成block，並將work push到cpuAgent處理，注意沒有蓋章

Worker. wait （對應於 1.8.4 的 resultLoop ） ：節點啟動的時候調用，循環監聽 recv 消息，將攜帶的block插入區塊鏈中、發送廣播消息（ NewMinedBlockEvent ）、發送消息 PostChainEvents （發送 ChainHeadEvent ，即 chainHeadCh ），其中的關鍵函數是 WriteBlockAndState 。

cpuAgent .update() :  在cpuAgent.start()->worker.start->miner.start->geth的命令行調用之後啟動循環，用於接收 commitNewWork 分配下來的work，關鍵函數 mine ，裡面調用 Seal ，主要是完成POW尋找nonce值的操作，發送 recv 消息通知worker，也可以叫做蓋章。

類圖如下：

具體結構不再贅述

流程：

Miner.update：用於監控是否有塊同步，如果有則停止挖礦，這個在POW這種競爭性出塊的環境中需要

mainLoop：收到newWorkCh消息後處理，調用commitNewWork中的commit發送taskCh消息

newWorkLoop：收到startCh消息和chainHeadCh消息後發送newWorkCh消息

resultLoop：循環監聽resultCh（seal發送）消息，將攜帶的block插入區塊鏈中，並發送廣播消息，關鍵函數WriteBlockAndState，並發送chainHeadCh消息

taskLoop：以前agent做的事情，收到taskCh消息後，調用seal，裡面發送resultCh消息

D. 以太坊ETH覆蓋或刪除處於pending狀態交易

有人肯定遇到跟我一樣的問題，賬號里還有一些eth，但是有一筆交易一直處於pending狀態，導致後續的交易全部卡死。除非這一筆pending狀態的交易被礦工打包。請注意nonce，由於每一個賬號的每一個交易nonce都是遞增的，因此如果用已經成功的交易的nonce重新交易，一定會報錯nonce too low。

1、發現有一筆訂單一直處於pending狀態，後續的所有交易都不能正常進行

2、解決方案，通過設置較高的gasprice來覆蓋或替換該交易

3、接下來，該賬號就可以正常轉賬啦。

目前市場上尚未找到能滿足該功能的工具/錢包，如需提供技術服務，請聯系作者，微信號：hqfeijian ，備註：以太坊替換交易

E. 以太坊GasLimit的計算方法

以太坊黃皮書上說的gasLimit的計算方法：

gasLimit = Gtransaction + Gtxdatanonzero × dataByteLength

需要注意的是這只是靜態的gas消耗，實際gas消耗還需要加上合約執行的開銷。

計算 IntrinsicGas的源碼位置 core/state_transition.go

相關源碼位置：internal/ethapi/api.go

EstimateGas 採用二分查找法獲取要評估交易的gas值。二分查找的下限是 param.TxGas , 如果 args 參數指定 Gas 大於 param.Gas ，那麼二分查找的上限就是 args.Gas ，否則以當前pending塊的block gas limit(後面簡稱BGL)作為二分查找的上限。 doCall 函數模擬智能合約的執行，經過多次嘗試找到智能合約能夠成功運行的最佳gas值。

由於二分查找的上限和BGL有關，而BGL和不是固定不變的，因此每次gas評估的結果不一定都是相同的，可能每個區塊周期就會變動一次。

在實際進行gas評估的時候，可能會出現類似下面的錯誤

該錯誤出現的最可能是合約執行中出錯。

How do you calculate gas limit for transaction with data in Ethereum?

F. ETH開發實踐——批量發送交易

在使用同一個地址連續發送交易時，每筆交易往往不可能立即到賬， 當前交易還未到賬的情況下，下一筆交易無論是通過 eth.getTransactionCount() 獲取nonce值來設置，還是由節點自動從區塊中查詢，都會獲得和前一筆交易同樣的nonce值，這時節點就會報錯 Error: replacement transaction underpriced

在構建一筆新的交易時，在交易數據結構中會產生一個nonce值， nonce是當前區塊鏈下，發送者(from地址)發出的交易(成功記錄進區塊的)總數， 再加上1。例如新構建一筆從A發往B的交易，A地址之前的交易次數為10，那麼這筆交易中的nonce則會設置成11， 節點驗證通過後則會放入交易池（txPool）,並向其他節點廣播，該筆交易等待礦工將其打包進新的區塊。

那麼，如果在先構建並發送了一筆從地址A發出的，nonce為11的交易，在該交易未打包進區塊之前， 再次構建一筆從A發出的交易，並將它發送到節點，不管是先通過web3的eth.getTransactionCount(A)獲取到的過往的交易數量，還是由節點自行填寫nonce， 後面的這筆交易的nonce同樣是11， 此時就出現了問題：

實際場景中，會有批量從一個地址發送交易的需求，首先這些操作可能也應該是並行的，我們不會等待一筆交易成功寫入區塊後再發起第二筆交易，那麼此時有什麼好的解決辦法呢？先來看看geth節點中交易池對交易的處理流程

如之前所說，構建一筆交易時如果不手動設置nonce值，geth節點會默認計算發起地址此前最大nonce數（寫入區塊的才算數），然後將其加上1， 然後將這筆交易放入節點交易池中的pending隊列，等到節點將其打包進區塊。

構建交易時，nonce值是可以手動設置的，如果當前的nonce本應該設置成11， 但是我手動設置成了13， 在節點收到這筆交易時， 發現pending隊列中並沒有改地址下nonce為11及12的交易， 就會將這筆nonce為13的交易放入交易池的queued隊列中。只有當前面的nonce補齊（nonce為11及12的交易被發現並放入pending隊列）之後，才會將它放入pending隊列中等待打包。

我們把pending隊列中的交易視為可執行的，因為它們可能被礦工打包進最新的區塊。 而queue隊列因為前面的nonce存在缺失，暫時無法被礦工打包，稱為不可執行交易。

那麼實際開發中，批量從一個地址發送交易時，應該怎麼辦呢？

方案一：那麼在批量從一個地址發送交易時， 可以持久化一個本地的nonce，構建交易時用本地的nonce去累加，逐一填充到後面的交易。（要注意本地的nonce可能會出現偏差，可能需要定期從區塊中重新獲取nonce，更新至本地）。這個方法也有一定的局限性，適合內部地址（即只有這個服務會使用該地址發送交易）。

說到這里還有個坑，許多人認為通過 eth.getTransactionCount(address, "pending") ，第二個參數為 pending ， 就能獲得包含本地交易池pending隊列的nonce值，但是實際情況並不是這樣， 這里的 pending 只包含待放入打包區塊的交易， 假設已寫入交易區塊的數量為20， 又發送了nonce為21，22，23的交易， 通過上面方法取得nonce可能是21（前面的21，22，23均未放入待打包區塊）， 也可能是22（前面的21放入待打包區塊了，但是22，23還未放入）。

方案二是每次構建交易時，從geth節點的pending隊列取到最後一筆可執行交易的nonce, 在此基礎上加1，再發送給節點。可以通過 txpool.content 或 txpool.inspect 來獲得交易池列表，裡面可以看到pending及queue的交易列表。

啟動節點時，是可以設置交易池中的每個地址的pending隊列的容量上限，queue隊列的上容量上限， 以及整個交易池的pending隊列和queue隊列的容量上限。所以高並發的批量交易中，需要增加節點的交易池容量。

當然，除了擴大交易池，控制發送頻率，更要設置合理的交易手續費，eth上交易寫入區塊的速度取決於手續費及eth網路的擁堵狀況，發送每筆交易時，設置合理的礦工費用，避免大量的交易積壓在交易池。

G. 跨行轉賬整整8天了仍未到帳，也沒退款

我們在轉賬之後，有時會出現轉賬遲遲未到賬的情況，很多用戶十分著急，甚至認為自己的幣丟失了。Tokenview收到了一封來自昵稱為港灣用戶的求助郵件。郵件中說，該用戶在進行USDT轉賬時發生了USDT丟失的情況。用戶提供了提幣地址，交易ID，接收地址以及轉賬金額和轉賬時間，問是否可以找回。

首先，我們需要先確定沒到賬的原因。一般來說，轉賬沒到賬的原因有四個：
1、地址填錯
2、網路擁堵，暫未到賬
3、確認數未達標，暫未入賬
4、手續費不足，交易被退回
我們一個個來分析。如果是第一種情況，地址填錯。地址填錯大約分二種情況，第一種情況是地址種類填錯，或者格式錯誤。這種情況下，轉賬可能無法順利進行，相應的錢包軟體會進行提示，如果交易不能發起，也就不存在丟幣的情況。但在種類填錯的情況下也不是不可能發起交易的。舉例來說，如果我們把USDT—OMNI提現到了USDT-ERC20，就會丟幣，這樣丟失的幣是無法找回的。第二種情況就是地址張冠李戴，是對應的鏈上地址，但是錯填成他人地址。這種情況交易將會順利發起，而此時交易上鏈後，基於區塊鏈不可逆的特性，任何人都無法對該筆交易進行撤回操作，除非接收方原因將幣轉回原地址。
如何判斷接收地址是否填寫錯誤呢？我們復制交易ID，或者直接復制自己的轉出地址，通過Tokenview區塊瀏覽器進行查詢。我們通過查詢該用戶提供的交易ID，可以發現，該用戶進行了火幣的一筆提現操作，其轉入地址與用戶提供的轉入地址不符，也就是說，出於某種原因，用戶將USDT轉去了錯誤的地址。

這種情況下，交易將是無法撤回的，除非改接收地址的持有人願意將這筆「天降之財」原路退回。但由於區塊鏈的匿名性，除了Tokenview標記出的交易所出入金地址及某些大戶地址外，其餘BTC、USDT地址我們是無法通過地址哈希定位其所有人的，因此可以說，在這種情況下，找回幣的幾率微乎其微。
第二種情況是網路擁堵。這種情況我們能做的就是等待交易打包上鏈。我們可以在tokenview.com的Pending交易池中看看交易是否存在。如：https://btc.tokenview.com/cn/pending。
第三種情況一般存在於交易平台充幣。當交易上鏈時，確認數為1，但由於不同交易所對確認數的要求不同，例如大部分對比特幣的確認數要求要達到6才會被確認充值成功，而以太坊則是12個。我們可以通過tokenview.com來查詢交易數。如果交易數還沒有達到要求，我們還需要再耐心等一下。
最後一種情況是手續費不足，交易被退回。這種情況交易會失敗。拿以太坊的轉賬為例，如果手續費不足，此交易將扣取手續費，並將ETH退回到轉出地址，並不存在丟幣的情況。
轉賬未到賬的幾種情況我們已經介紹完畢了。其中最關鍵的是大家在轉賬之前一定要再三確認交易地址是否填寫無誤。如果是進行USDT的轉賬，一定要確認其USDT類型。是OMNI，還是ERC20，還是TRC20，避免發生填錯類型而丟幣的意外，從而造成損失。