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

兩 個(gè) 腳 本

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

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

在開始之前，您需要滿足以下幾項(xiàng)要求：

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

· Node.js和NPM

· 用npm init初始化的新目錄

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

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

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

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

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

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

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

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

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

底部的間隔功能每7秒檢查一次當(dāng)前區(qū)塊。我選擇此數(shù)字是因?yàn)橐蕴坏钠骄鰤K時(shí)間為15秒，我們不想錯(cuò)過任何區(qū)塊。該程序的問題在于它不依賴統(tǒng)計(jì)異常值。例如如果一個(gè)區(qū)塊在7秒內(nèi)被挖掘，則可能會(huì)完全丟失該區(qū)塊。而且如果我們嘗試通過減少輪詢間隔來緩解這種情況，則會(huì)發(fā)現(xiàn)我們需要一個(gè)非?？焖俚腎nternet連接來處理所有異步網(wǎng)絡(luò)I/O。

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

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

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

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

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

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

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

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

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

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

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

最后是我們的索引文件：

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