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

兩 個 腳 本

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

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

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

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

· Node.js和NPM

· 用npm init初始化的新目錄

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

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

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

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

接下來，我們將創(chuàng)建實際的交易檢查器：

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

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

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

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

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

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

也不要忘記返回這個函數(shù)。

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

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

- 通知是實時發(fā)送的，用于當(dāng)前事件，而不是過去事件。可以調(diào)整前一個程序以搜索一系列塊之間的事務(wù)，但這對該程序不起作用。

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

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

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

現(xiàn)在對于第二個版本的事務(wù)檢查器：

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

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

最后是我們的索引文件：

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