⑴ 死磕以太坊源碼分析之Kademlia演算法
Kademlia演算法是一種點對點分布式哈希表(DHT)，它在復雜環境中保持一致性和高效性。該演算法基於異或指標構建拓撲結構，簡化了路由過程並確保了信息的有效傳遞。通過並發的非同步查詢，系統能適應節點故障，而不會導致用戶等待過長。
在Kad網路中，每個節點被視作一棵二叉樹的葉子，其位置由ID值的最短前綴唯一確定。節點能夠通過將整棵樹分割為連續、不包含自身的子樹來找到其他節點。例如，節點0011可以將樹分解為以0、01、000、0010為前綴的子樹。節點通過連續查詢和學習，逐步接近目標節點，最終實現定位。每個節點都需知道其各子樹至少一個節點，這有助於通過ID值找到任意節點。
判斷節點間距離基於異或操作。例如，節點0011與節點1110的距離為36，高位差異對結果影響更大。異或操作的單向性確保了查詢路徑的穩定性，不同起始節點進行查詢後會逐步收斂至同一路徑，減輕熱門節點的存儲壓力，加快查詢速度。
Kad路由表通過K桶構建，每個節點保存距離特定范圍內的節點信息。K桶根據ID值的前綴劃分距離范圍，每個桶內信息按最近至最遠的順序排列。K桶大小有限，確保網路負載平衡。當節點收到PRC消息時，會更新相應的K桶，保持網路穩定性和減少維護成本。K桶老化機制通過隨機選擇節點執行RPC_PING操作，避免網路流量瓶頸。
Kademlia協議包括PING、STORE、FIND_NODE、FIND_VALUE四種遠程操作。這些操作通過K桶獲得節點信息，並根據信息數量返回K個節點。系統存儲數據以鍵值對形式，BitTorrent中key值為info_hash，value值與文件緊密相關。RPC操作中，接收者響應隨機ID值以防止地址偽造，並在回復中包含PING操作校驗發送者狀態。
Kad提供快速節點查找機制，通過參數調節查找速度。節點x查找ID值為t的節點，遞歸查詢最近的節點，直至t或查詢失敗。遞歸過程保證了收斂速度為O(logN)，N為網路節點總數。查找鍵值對時，選擇最近節點執行FIND_VALUE操作，緩存數據以提高下次查詢速度。
數據存儲過程涉及節點間數據復制和更新，確保一致性。加入Kad網路的節點通過與現有節點聯系，並執行FIND_NODE操作更新路由表。節點離開時，系統自動更新數據，無需發布信息。Kad協議設計用於適應節點失效，周期性更新數據到最近鄰居，確保數據及時刷新。
⑵ 以太坊的 ChainId 與 NetworkId
ChainId 是 EIP-155 引入的一個用來區分不同 EVM 鏈的一個標識。如下圖所示，主要作用就是避免一個交易在簽名之後被重復在不同的鏈上提交。最開始主要是為了防止以太坊交易在以太經典網路上重放或者以太經典交易在以太坊網路上重放。在以太坊網路上是從 2675000 這個區塊通過 Spurious Dragon 這個硬分叉升級激活。
引入 ChainId 後，帶來了哪些影響呢？
NetworkId 主要用來在網路層標識當前的區塊鏈網路。NetworkId 不一致的兩個節點無法建立連接。
NetworkId 無法通過配置文件指定，智能通過參數 --networkid 來指定。所以我們啟動自己私鏈節點上需要記得加上這個參數。如果不加這個參數也不指定網路類型，默認 NetworkId 的值和以太坊主網一致。
不是。
這個根據上面的介紹可以很明顯的看出，兩者並沒有非常高的關聯度。
網上幾乎所有提到搭建以太坊私鏈的文章，都要強調 NetworkId 需要和 genesis 文件里 ChainId 的值相同。事實上是沒必要的。
就像下面這張圖展示的這樣，很多已經在主網運行的 EVM 鏈，它們的 ChainId 和 NetworkId 並不相同。比如以太經典，它的 ChainId 是 61，但 NetworkId 和以太坊主網一樣都是 1。
之所以很多文章強調 ChainId 和 NetworkId 要保持一致，可能因為在某一段時間內，一些開發工具比如 MetaMask，會把 NetworkId 當作 ChainId 來用。不過現在 MetaMask 已經支持自定義 ChainId，以太坊也添加了 「eth_chainId」 這個 RPC API，相信兩者誤用的情況會越來越少。
⑶ etherscan.io是如何獲取區塊鏈詳細數據的
etherscan.io 等區塊鏈瀏覽器獲取區塊鏈數據的主要方式是通過搭建全節點，調用全節點的 RPC 方法獲取所需信息。web3.eth 也採用相似策略。為了獲取特定數據，開發者可通過解析全節點源代碼或資料庫，但此類操作技術難度較高，要求深入了解區塊鏈原理與數據存儲結構。
以太坊全節點主要有兩種版本：Geth 和 Parity。Parity 擁有更強大的功能，但資源佔用更大。
獲取合約地址的交易數據時，需注意合約調用產生的結果通常不上鏈，故 Geth 全節點無法獲取內部交易信息。而 Parity 提供了 trace 介面，能夠通過以太坊虛擬機（EVM）回放，獲取內部交易詳情。etherscan.io 則通過 trace 介面獲取此類數據。
ERC20 合約交易數據可通過 Parity 全節點調用 eth_getFilterLogs 方法篩選並獲取，此介面詳細說明可見於相關文檔。
另外，谷歌 BigQuery 提供了全面的鏈上數據查詢服務，包括比特幣、分叉鏈、以太坊、以太經典等。但服務費用按每次搜索的數據量計費，每 TB 5 美元，成本不菲。BigQuery 並且開源了數據解析代碼，用戶可根據自身需求搭建自用資料庫。
在區塊鏈數據獲取方面，etherscan.io 通過搭建全節點或調用高階介面實現了數據的有效獲取。同時，BigQuery 等工具提供了便捷的數據查詢途徑，盡管存在費用問題，但其提供的鏈上數據覆蓋廣泛，為研究與分析提供了寶貴資源。
⑷ 以太坊如何使用web3.js或者rpc介面獲取交易數據交易時間與確認數
如果要查詢主網上的交易記錄，可以使用etherscan。但是，如果是你自己搭建的私鏈，應該如何查詢交易記錄呢？
答案是你需要自己監聽鏈上的日誌，存到資料庫里，然後在這個資料庫中查詢。例如：
varaddr=""
varfilter=web3.eth.filter({fromBlock:0,toBlock:'latest',address:addr});
filter.get(function(err,transactions){
transactions.forEach(function(tx){
vartxInfo=web3.eth.getTransaction(tx.transactionHash);
//這時可以將交易信息txInfo存入資料庫
});
});
web3.eth.filter()用來監聽鏈上的日誌，web3.eth.getTransaction()用來提取指定交易的信息，一旦獲得交易信息，就可以存入資料庫供查詢用了。
推薦一個實戰入門，你可以看看：以太坊教程
⑸ 死磕以太坊源碼分析之挖礦流程
以太坊的挖礦流程主要由miner包負責，它通過miner對象來管理操作，內部使用worker對象實現整體功能。miner決定礦工的啟動與停止，並能設置礦工地址以獲取獎勵。
worker.go文件中的worker對象負責挖礦的細節，其工作流程包含四個主要循環，通過多個channel完成任務調度、新任務提交、任務結果處理等。
新任務由newWorkLoop循環產生，此過程中，resubmitAdjustCh與resubmitIntervalCh兩個輔助信號用於調整計時器的頻率，resubmitAdjustCh根據歷史情況計算合理的間隔時間，而resubmitIntervalCh則允許外部實時修改間隔時間。
mainLoop循環則負責提交新任務並處理結果。TaskLoop提交任務，resultLoop則在新塊成功生成後執行相關操作。
啟動挖礦的參數設置定義在cmd/utils/flags.go文件中，提供了一系列選項，如開啟自動挖礦、設置並行PoW計算的協程數、配置挖礦通知、控制區塊驗證、設置Gas價格、確定Gas上限、指定挖礦獎勵賬戶、自定義區塊頭額外數據、設置重新挖礦間隔等。
可以採用多種方式啟動挖礦，例如通過控制台命令、RPC介面等。設置參數時，可參考官方文檔或相關指南進行調整。
分析代碼從miner.go的New函數開始，初始化canStart狀態以控制挖礦流程。若Downloader模塊正在同步或已完成，則啟動挖礦，否則停止。隨後進入mainLoop處理startCh，清除舊任務、提交新任務。
生成新任務通過newWorkCh完成，進入CommitNewWork函數，其中包含組裝header、初始化共識欄位、創建挖礦環境、添加叔塊等步驟。添加叔塊時進行校驗，確保區塊符合規定。若條件允許，任務會提交空塊、填充交易，並執行交易以生成最終塊。
交易執行成功後，塊數據被存入資料庫，並廣播至網路。若執行出錯，則回滾至上一個快照狀態。成功出塊後，新區塊被驗證、確認，並納入未確認區塊集中。若新區塊穩定，將正式插入鏈中。
整個挖礦流程相對簡單，主要由四個循環相互協作完成從挖礦啟動到新任務生成、任務提交、成功出塊的全過程。共識處理細節將在後續文章中詳細闡述。
⑹ 如何使用 Etherscan 的 API
雖然以太坊提供了 Web3 和 Json Rpc 這 2 種 API，geth 也額外提供了一些 API ，但是對於開發以太坊應用來說還是顯得有些不足，比如說獲取交易記錄的時間，需要先通過交易的 hash 找到該交易對應的區塊 id，然後才能找到對應的時間，查詢起來相當不方便。
好在 Etherscan 對外提供了一些公共的 API，給我們提供了額外的能力來處理更多的業務場景。
為了方便開發人員更好地使用 ethersacn.io ，網站提供了 一系列 API 供開發人員使用。
API 的使用非常簡單，基本上都是 get 方法，通過 http 請求就可以直接調用，在每個 Api 的說明文檔都有對應的例子可以查看。
API 主要包含以下模塊：賬號、智能合約、交易、區塊、事件日誌、代幣及工具等。
賬號相關的 API，有獲取賬號金額，獲取交易記錄等，該模塊提供的 API 最多。
API 示例
https://api.etherscan.io/api?mole)=account&action=balance&address=&tag=latest&apikey=YourApiKeyToken
參數說明
其中 mole、action、apikey 是每個 API 都有的參數，其他的參數則因不同 API 而不同。
返回結果
API 示例
https://api.etherscan.io/api?mole=account&action=balancemulti&address=,,&tag=latest&apikey=YourApiKeyToken
參數說明
（前面有講過的參數就不講了，下同）
與單個賬號金額 API 相比，參數 address 用 , 號分隔多個賬號，最多可支持 20 個賬號的金額查詢。
返回結果
API 示例
https://api.etherscan.io/api?mole=account&action=txlist&address=&startblock=0&endblock=99999999&page=1&offset=10&sort=asc&apikey=YourApiKeyToken
參數說明
返回結果
API 示例
https://api.etherscan.io/api?mole=account&action=txlistinternal&address=&startblock=0&endblock=2702578&page=1&offset=10&sort=asc&apikey=YourApiKeyToken
參數說明
參數與上一個 API 基本相同，只有 action 是 txlistinternal 這一點不同，這 2 種交易的區別是什麼呢？簡單的理解就是「正常」的交易是會記錄到區塊鏈上的，而「內部」交易是指不會記錄到區塊鏈上的記錄，比如交易失敗的記錄。
另外這個 API 還可以通過交易 hash 查看交易的詳情。
https://api.etherscan.io/api?mole=account&action=txlistinternal&txhash=&apikey=YourApiKeyToken
返回結果
API 示例
參數說明
返回結果
API 示例
參數說明
返回結果
智能合約相關的 API，其實只有一個獲取智能合約介面的 API，但是這個 API 非常有用。
API 示例
參數說明
智能合約的 abi 就是一個 json 對象，通過這個對象我們可以調用其介面方法，後面會寫一篇文章介紹如何操作 abi 對象，敬請期待。
返回結果
返回結果內容比較長，這里省略，就是一個 json 對象，感興趣的可以自行調用該 API 看結果。
賬號和智能合約的 API 已經能滿足大部分的業務需求了，其他模塊的 API 感覺沒什麼太大的作用，這里就不介紹了，感興趣的讀者可以自行查閱。
這里再說下 API 的使用限制，剛才提到每個 API 都有一個 apikey 參數，如果 API 沒加上這個參數的話，每個 API 的請求次數不能超過 5 次每秒。
Etherscan 提供的這些 API 有些是和以太坊提供的 API 有重復的，比如說獲取賬號金額，獲取事件日誌記錄等，但有一些 API 給我們帶來了很大的便利性，比如獲取賬號交易記錄，有了這個 API 就不用使用幾個原生 API 進行各種數據拼接了。
另外 Etherscan 的這套 API 在 Rinkeby 測試網路也有一套一模一樣的，區別只是前面的 url 不同，Rinkeby 的是： api-rinkeby.etherscan.io ，感興趣的同學可以去試試。
⑺ 以太坊event log查詢與解析
從 ethereum json-rpc文檔 的文檔中找到一個同時指定多個事件以 OR 或者 AND 查詢的方法.以下是查詢 Approval 或 Transfer 事件的方法：
topics 欄位中指定查詢條件的語法參考上面鏈接。
通過 getTransactionReceipt 在ropsten測試網上查詢到交易號為 的交易詳情
這個交易從 "from": "" 發送到合約地址 "to": "" .這個合約為ERC20代幣合約.從 topics 的第一個元素可以看出合約中產生了 Transfer 事件(topics第一個元素一定是事件的keccak哈希). topics 的第二個欄位是轉出代幣的地址，第三個欄位是接收者地址.ERC20代幣 Transfer 事件的簽名為
我們注意到 Transfer 事件的第一個和第二個參數被標記為 indexed , 因此他們的值被放在 topics array 中. 由於tokens參數沒有標記為 indexed , 所以他的值被放在 data 欄位. 如果事件中有多個欄位未標記為 indexed ， 那麼他們的值都會被記錄在 data 欄位中。