最近在一個新項目上工作時，我無意中發現了一個問題：我必須將所有的交易或多或少地實時發送到一個給定的帳戶。在查看了Web3.js API文檔和堆棧溢出之后，沒有明確的方法可以執行此操作，因此我嘗試自己創建一些程序。，這就是該程序產生的原因。

兩 個 腳 本

經過多次嘗試和錯誤之后，我得出兩個腳本，它們都適合不同的狀態，第一個非常慢，但更具擴展性，而另一個非常輕量級，但不太可定制。讓我們一起探索它們。

檢查某個地址的事務可能看起來很簡單，但實際上比我最初想象的要困難得多。有人希望我們可以通過監聽某種網絡事件來監視以太坊地址，以獲取傳入事務，但這種功能目前還不存在。

在開始之前，您需要滿足以下幾項要求：

· 正在運行的以太坊節點，如Geth或Infura

· Node.js和NPM

· 用npm init初始化的新目錄

我們只需要一個依賴項-web3.js（請查看文檔）。與以太坊網絡交互的JavaScript API。 所以一定要安裝npm。

首先創建一個為我們初始化web3客戶端的模塊：

請注意，本文中的每個代碼段都是一個單獨的js文件，我們將其與index.js結合在一起

該模塊接收Web3包并返回一個初始化的客戶端。 我在rinkeby測試網上使用了一個Infura Ethereum節點，并且如果您決定也這樣做（我建議這樣做），請確保使用正確的密鑰替換YOUR_INFURA_API_KEY。

接下來，我們將創建實際的交易檢查器：

我們的第二個模塊使用該web3客戶端來查詢實際網絡。我們有一個私有account變量，您應將其替換為您感興趣的地址，然后返回checkLastBlock函數。首先我們檢索最新的區塊，并將數字記錄到控制臺。這樣的代碼塊看起來就是這樣（我排除了一些對我們沒有用的字段）：

您可以看到諸如number、nonce和hash之類的字段，但我們現在真正感興趣的是transactions字段。這是一個數組，包含該塊中包含的所有事務哈希。

在transactionChecker.js的第9行，我們檢查block和block.transactions數組是否不為空，在第10行，我們遍歷該數組。對于數組中的每個交易哈希，我們請求實際交易。事務如下所示：

如果我們現在發現to字段（事務接收端的地址）等于我們的地址（不要忘記toLowerCase（）函數），那么我們已經找到了要查找的內容，并且可以將一些數據記錄到控制臺。（如果事務不包含“收件人”字段，則為合約創建）

底部的間隔功能每7秒檢查一次當前區塊。我選擇此數字是因為以太坊的平均出塊時間為15秒，我們不想錯過任何區塊。該程序的問題在于它不依賴統計異常值。例如如果一個區塊在7秒內被挖掘，則可能會完全丟失該區塊。而且如果我們嘗試通過減少輪詢間隔來緩解這種情況，則會發現我們需要一個非常快速的Internet連接來處理所有異步網絡I/O。

有利的一面是，我們可以擴展此腳本，例如檢查一系列區塊之間的所有到該帳戶的交易，如下所示：

也不要忘記返回這個函數。

如果您對我的模塊編寫方式完全感到困惑：我導出所謂的工廠函數，這是JavaScript的絕佳設計模式。

第二個程序利用以太坊的pub/sub。pub/sub是一個系統，發布者通過該系統不斷向網絡廣播與特定主題相關的事件，客戶端（訂閱者）可以訂閱這些事件。這比像我們在第一個程序中那樣不停地對網絡進行投票要好得多，也快得多。但是您必須考慮以下幾個方面：

- 通知是實時發送的，用于當前事件，而不是過去事件?？梢哉{整前一個程序以搜索一系列塊之間的事務，但這對該程序不起作用。

- 訂閱需要全雙工連接。幸運的是，Infura和Geth都以websocket的形式提供了這種連接。

由于我們是實時監控帳戶，因此這些要點不會打擾我們，讓我們繼續。我現在在一個新的npm目錄中工作，如果您正在編碼，請記住這一點。

首先我們必須創建我們的客戶。對于此程序，我們需要一個普通的http提供程序以及一個websocket提供程序。在我們的代碼中，我們將兩者都返回到一個對象中-web3http將是http客戶端，web3是websocket客戶端：

現在對于第二個版本的事務檢查器：

讓我們把這個分解。有幾個主題可以訂閱，如newBlockHeaders或logs。日志是理想的，但是這個訂閱主題還不起作用。所以我們將使用pendingTransactions訂閱。這發生在第5行。我們的訂閱是事件發射器，當有人發送新交易（因此尚未確認）的那一刻，它就向我們發送該交易的交易哈希。這發生在函數watchTransactions中，我們在第11行公開了該函數。

由于這些事務還沒有被確認，我們將使用setTimeout函數來阻止每一個事件的進一步代碼執行，直到一分鐘后，希望到那時，該事務將被挖掘出來。因為在那之后，我們實際上只做了與第一個程序相同的事情：檢索事務，并檢查我們的地址是否是接收端的地址。

最后是我們的索引文件：

該程序更加優雅，并且不會占用大量資源。但是請注意，這兩個程序都存在一些可靠性問題。我們討論的第一個區塊：如果區塊時間比平均區塊時間低很多，則可能會錯過該區塊。對于第二筆，如果有人支付了很少的費用，那么肯定不會在一分鐘后被挖掘。在我的項目中，我將setTimeout增加到5分鐘，因為出于我的考慮，這仍然在范圍之內。但是如果要實際使用此功能，請小心。理想情況下，我們將訂閱日志，但這仍然是真正的錯誤，因此是一個非常糟糕的主意。
責任編輯；zl