如何運(yùn)行以太坊節(jié)點(diǎn)
掃描二維碼
隨時隨地手機(jī)看文章
最近在一個新項目上工作時,我無意中發(fā)現(xiàn)了一個問題:我必須將所有的交易或多或少地實(shí)時發(fā)送到一個給定的帳戶。在查看了Web3.js API文檔和堆棧溢出之后,沒有明確的方法可以執(zhí)行此操作,因此我嘗試自己創(chuàng)建一些程序。,這就是該程序產(chǎn)生的原因。
兩 個 腳 本
經(jīng)過多次嘗試和錯誤之后,我得出兩個腳本,它們都適合不同的狀態(tài),第一個非常慢,但更具擴(kuò)展性,而另一個非常輕量級,但不太可定制。讓我們一起探索它們。
檢查某個地址的事務(wù)可能看起來很簡單,但實(shí)際上比我最初想象的要困難得多。有人希望我們可以通過監(jiān)聽某種網(wǎng)絡(luò)事件來監(jiān)視以太坊地址,以獲取傳入事務(wù),但這種功能目前還不存在。
在開始之前,您需要滿足以下幾項要求:
· 正在運(yùn)行的以太坊節(jié)點(diǎn),如Geth或Infura
· Node.js和NPM
· 用npm init初始化的新目錄
我們只需要一個依賴項-web3.js(請查看文檔)。與以太坊網(wǎng)絡(luò)交互的JavaScript API。 所以一定要安裝npm。
首先創(chuàng)建一個為我們初始化web3客戶端的模塊:
請注意,本文中的每個代碼段都是一個單獨(dú)的js文件,我們將其與index.js結(jié)合在一起
該模塊接收Web3包并返回一個初始化的客戶端。 我在rinkeby測試網(wǎng)上使用了一個Infura Ethereum節(jié)點(diǎn),并且如果您決定也這樣做(我建議這樣做),請確保使用正確的密鑰替換YOUR_INFURA_API_KEY。
接下來,我們將創(chuàng)建實(shí)際的交易檢查器:
我們的第二個模塊使用該web3客戶端來查詢實(shí)際網(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ù)組中的每個交易哈希,我們請求實(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ù)字是因?yàn)橐蕴坏钠骄鰤K時間為15秒,我們不想錯過任何區(qū)塊。該程序的問題在于它不依賴統(tǒng)計異常值。例如如果一個區(qū)塊在7秒內(nèi)被挖掘,則可能會完全丟失該區(qū)塊。而且如果我們嘗試通過減少輪詢間隔來緩解這種情況,則會發(fā)現(xiàn)我們需要一個非??焖俚腎nternet連接來處理所有異步網(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)行投票要好得多,也快得多。但是您必須考慮以下幾個方面:
- 通知是實(shí)時發(fā)送的,用于當(dāng)前事件,而不是過去事件??梢哉{(diào)整前一個程序以搜索一系列塊之間的事務(wù),但這對該程序不起作用。
- 訂閱需要全雙工連接。幸運(yùn)的是,Infura和Geth都以websocket的形式提供了這種連接。
由于我們是實(shí)時監(jiān)控帳戶,因此這些要點(diǎn)不會打擾我們,讓我們繼續(xù)。我現(xiàn)在在一個新的npm目錄中工作,如果您正在編碼,請記住這一點(diǎn)。
首先我們必須創(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ù)將被挖掘出來。因?yàn)樵谀侵?,我們?shí)際上只做了與第一個程序相同的事情:檢索事務(wù),并檢查我們的地址是否是接收端的地址。
最后是我們的索引文件:
該程序更加優(yōu)雅,并且不會占用大量資源。但是請注意,這兩個程序都存在一些可靠性問題。我們討論的第一個區(qū)塊:如果區(qū)塊時間比平均區(qū)塊時間低很多,則可能會錯過該區(qū)塊。對于第二筆,如果有人支付了很少的費(fèi)用,那么肯定不會在一分鐘后被挖掘。在我的項目中,我將setTimeout增加到5分鐘,因?yàn)槌鲇谖业目紤],這仍然在范圍之內(nèi)。但是如果要實(shí)際使用此功能,請小心。理想情況下,我們將訂閱日志,但這仍然是真正的錯誤,因此是一個非常糟糕的主意。