『壹』 以太坊多節點私有鏈部署
假設兩台電腦A和B
要求：
1、兩台電腦要在一個網路中，能ping通
2、兩個節點使用相同的創世區塊文件
3、禁用ipc;同時使用參數--nodiscover
4、networkid要相同，埠號可以不同
1.4 搭建私有鏈
1.4.1 創建目錄和genesis.json文件
創建私有鏈根目錄./testnet
創建數據存儲目錄./testnet/data0
創建創世區塊配置文件./testnet/genesis.json
1.4.2 初始化操作
cd ./eth_test
geth --datadir data0 init genesis.json
1.4.3 啟動私有節點
1.4.4 創建賬號
personal.newAccount()
1.4.5 查看賬號
eth.accounts
1.4.6 查看賬號余額
eth.getBalance(eth.accounts[0])
1.4.7 啟動&停止挖礦
啟動挖礦：
miner.start(1)
其中 start 的參數表示挖礦使用的線程數。第一次啟動挖礦會先生成挖礦所需的 DAG 文件，這個過程有點慢，等進度達到 100% 後，就會開始挖礦，此時屏幕會被挖礦信息刷屏。
停止挖礦，在 console 中輸入：
miner.stop()
挖到一個區塊會獎勵5個以太幣，挖礦所得的獎勵會進入礦工的賬戶，這個賬戶叫做 coinbase，默認情況下 coinbase 是本地賬戶中的第一個賬戶，可以通過 miner.setEtherbase() 將其他賬戶設置成 coinbase。
1.4.8 轉賬
目前，賬戶 0 已經挖到了 3 個塊的獎勵，賬戶 1 的余額還是0：
我們要從賬戶 0 向賬戶 1 轉賬，所以要先解鎖賬戶 0，才能發起交易：
發送交易，賬戶 0 -> 賬戶 1：
需要輸入密碼 123456
此時如果沒有挖礦，用 txpool.status 命令可以看到本地交易池中有一個待確認的交易，可以使用 eth.getBlock("pending", true).transactions 查看當前待確認交易。
使用 miner.start() 命令開始挖礦：
miner.start(1);admin.sleepBlocks(1);miner.stop();
新區塊挖出後，挖礦結束，查看賬戶 1 的余額，已經收到了賬戶 0 的以太幣：
web3.fromWei(eth.getBalance(eth.accounts[1]),'ether')
用同樣的genesis.json初始化操作
cd ./eth_test
geth --datadir data1 init genesis.json
啟動私有節點一,修改 rpcport 和port
可以通過 admin.addPeer() 方法連接到其他節點，兩個節點要要指定相同的 chainID。
假設有兩個節點：節點一和節點二，chainID 都是 1024，通過下面的步驟就可以從節點二連接到節點一。
首先要知道節點一的 enode 信息，在節點一的 JavaScript console 中執行下面的命令查看 enode 信息：
admin.nodeInfo.enode
" enode://@[::]:30303 "
然後在節點二的 JavaScript console 中執行 admin.addPeer()，就可以連接到節點一：
addPeer() 的參數就是節點一的 enode 信息，注意要把 enode 中的 [::] 替換成節點一的 IP 地址。連接成功後，節點一就會開始同步節點二的區塊，同步完成後，任意一個節點開始挖礦，另一個節點會自動同步區塊，向任意一個節點發送交易，另一個節點也會收到該筆交易。
通過 admin.peers 可以查看連接到的其他節點信息，通過 net.peerCount 可以查看已連接到的節點數量。
除了上面的方法，也可以在啟動節點的時候指定 --bootnodes 選項連接到其他節點。 bootnode 是一個輕量級的引導節點，方便聯盟鏈的搭建 下一節講 通過 bootnode 自動找到節點
參考： https://cloud.tencent.com/developer/article/1332424
『貳』 2021-01-19 記錄一次以太坊nonce值的問題
之前在做後端介面的時候，封裝了構造交易及發送交易這一層，其中構造交易的時候，獲取用戶的nonce這里，沒有自己維護，而是從鏈上獲取，且之前由於一些業務這里沒有做隊列，導致前端並發調用的時候，會產生一個賬戶同時構造兩個相同nonce值得交易，最終會導致失敗一條。
Client.PendingNonceAt 是從pending中獲取該賬戶的本次交易改用的nonce，本以為這里已經處理了就沒管，不曾想，還是會出現上面的交易重復的bug。
經修改，如果是特殊賬戶，可在業務層自行維護計數器做nonce值，維護成本較大，且復雜。
第二種 就是這里加個隊列，畢竟及時性不是區塊鏈該有的東西。
『叄』 以太坊ete轉賬不到
因為網路有一定的延遲原因,所以會導致轉賬成功,但是沒有到賬。
以太坊投資者在某個交易所平台當中進行了以太坊提現，結果發現eth沒收到；是一些投資者在進行購入以太坊購買交易過程中，已經按照提示支付了對應的購買價款和手續費，但是卻發現eth沒收到。網路上所反映的有關「eth沒收到」的情況大致就如此，除此之外可能還存在其他的一些與「eth沒收到」有關的咨詢，但是大致仍然脫離不了這兩類范疇。
我們在轉賬之後，有時會出現轉賬遲遲未到賬的情況，很多用戶十分著急，甚至認為自己的幣丟失了。Tokenview收到了一封來自昵稱為港灣用戶的求助郵件。郵件中說，該用戶在進行USDT轉賬時發生了USDT丟失的情況。用戶提供了提幣地址，交易ID，接收地址以及轉賬金額和轉賬時間，問是否可以找回。
『肆』 以太坊轉賬流程
發起:用戶在本地的以太坊錢包軟體中選擇要發送的交易地址(From)、輸入目標地址(To)、金額(Value)、是否部署或調用合(Data)、手續費單價(Gasprice)等,確認發送至以太坊節點節點和錢包可以是同一台
廣播:節點收到(或自己發起)交易後,會對交易進行驗證。驗證:交易的簽名、發起賬號的余額是否能支付轉賬余額與手續費、Nonce是否為賬號已發出的交易數。驗證為合法後,將交易加入節點的交易池中交易池中存儲著待打包的交
安裝以太坊瀏覽器錢包插件,創建錢包,獲取虛擬以太幣,進行轉賬交易。 實驗內容 學習 初識以太坊,發送交易 1.學習《初始以太坊,發送交易》,虛擬以太幣交易。
『伍』 別人轉賬給我，結果顯示資金凍結了24小時後，等待賬戶自動恢復，該怎麼辦
日常生活中的轉賬和區塊鏈轉賬有著本質上的不同，這種不同造成了區塊鏈轉賬狀態理解上的復雜。
我們會看到「等待確認」「確認中」「交易失敗」「成功」等狀態，其中有些屬於區塊鏈轉賬的特有狀態。
銀行轉賬
日常生活中的轉賬往往有兩個步驟：支付和清算。
平常我們通過支付寶消費、銀行卡轉賬，都屬於「支付」，本質是信息的記錄，記下一個債權債務憑證。而這種憑證需要被落實，也就是「清算」，本質是資金的流動。
一個常見的情形：
從我的招行卡往你的工行卡上轉賬 200 塊。
這個過程有兩個步驟：
當我成功轉給你 200 塊，這一步對你和我來說是「支付」，本質是信息流；對招行和工行而言，則是建立債權債務關系，它記了一張欠條：招行欠工行 200 塊。
然後是銀行們定期在央行清算系統中落實彼此間復雜的債權關系（第一步中的「招行欠工行 200 塊」是千絲萬縷之一）。這時，就是通過「清算」將信息流變成了真實的資金流。
對我們來說，第一步中轉賬按鈕一確定，你放心我也放心。可實際到這里，只是第一步，往後真正耗時的操作無聲無息地隱藏在整個金融基礎設施和系統的周期運轉中。它們不為常人道，卻是我們便利金融生活的基石。
Photo by José Martín Ramírez C on Unsplash
區塊鏈轉賬
它有支付和清算嗎？這個概念其實在這里不存在了。區塊鏈轉賬將這兩步驟合二為一，鏈上的每一筆轉賬都記錄著真實的資金流動。
區塊鏈作為一個公共賬本，公開透明，不可篡改。
也正因此，在它上面的轉賬有更復雜的狀態，這個賬本不容有錯，必須謹慎記錄。
所以我們看到這些狀態：「等待確認」「確認中」「交易失敗」與「成功」
「等待確認」：等待礦工確認轉賬信息，打包到區塊中；
「確認中」：一個區塊確認不夠安全，需要多些確認，這樣我們就能理解為什麼以太坊轉賬需要 12 個區塊確認才算作成功；
「交易失敗」：如果你給的礦工費不夠，不足以讓礦工確認轉賬信息，就會失敗（也可能是其他原因導致）；
「成功」：此時，你的轉賬記錄就在區塊鏈賬本上，不可篡改，記錄可查。
『陸』 以太坊轉帳二十小時沒到帳
新手第一次轉以太坊難免會緊張，因為不清楚以太坊轉賬多久到賬，所以每一秒的等待都是焦急的。以太坊轉賬的網路速度比較快，因為以太坊網路解決了比特幣網路中擴展性不足的問題，以太坊網路也比比特幣網路速度快。通常情況下以太坊轉賬只需要幾分鍾就可以到賬。若是你進行以太坊轉賬遲遲沒有收到到賬信息，你可以咨詢客服，或者自己查找是不是其中某個流程出現了錯誤。不論是轉比特幣還是以太坊，都需要手續費。因為手續費是給礦工的一種鼓勵，也是對礦工電費的一種補償。礦工們要確認每一筆交易很不容易，所以他們也需要報酬
『柒』 以太坊轉幣失敗
交易未被打包不會扣除礦工費，絕大多數未被打包的情況是礦工費設置的過低導致的。
轉賬失敗大致分為兩種情況：一種情況是交易未被打包導致轉賬失敗，另外一種情況是交易在打包的過程中發生了錯誤導致交易失敗。
轉賬時設置合適的礦工費。在imToken2。0國際版中，設置礦工費的滑動桿最大值和最小值都是從以太坊網路實時獲取的，推薦的礦工費就是能夠保證你這筆交易成功的最小值，所以只要按照App內部推薦的礦工費數值設置就可以了。
『捌』 以太坊ETH覆蓋或刪除處於pending狀態交易
有人肯定遇到跟我一樣的問題，賬號里還有一些eth，但是有一筆交易一直處於pending狀態，導致後續的交易全部卡死。除非這一筆pending狀態的交易被礦工打包。請注意nonce，由於每一個賬號的每一個交易nonce都是遞增的，因此如果用已經成功的交易的nonce重新交易，一定會報錯nonce too low。
1、發現有一筆訂單一直處於pending狀態，後續的所有交易都不能正常進行
2、解決方案，通過設置較高的gasprice來覆蓋或替換該交易
3、接下來，該賬號就可以正常轉賬啦。
目前市場上尚未找到能滿足該功能的工具/錢包，如需提供技術服務，請聯系作者，微信號：hqfeijian ，備註：以太坊替換交易
『玖』 ETH開發實踐——批量發送交易
在使用同一個地址連續發送交易時，每筆交易往往不可能立即到賬， 當前交易還未到賬的情況下，下一筆交易無論是通過 eth.getTransactionCount() 獲取nonce值來設置，還是由節點自動從區塊中查詢，都會獲得和前一筆交易同樣的nonce值，這時節點就會報錯 Error: replacement transaction underpriced
在構建一筆新的交易時，在交易數據結構中會產生一個nonce值， nonce是當前區塊鏈下，發送者(from地址)發出的交易(成功記錄進區塊的)總數， 再加上1。例如新構建一筆從A發往B的交易，A地址之前的交易次數為10，那麼這筆交易中的nonce則會設置成11， 節點驗證通過後則會放入交易池（txPool）,並向其他節點廣播，該筆交易等待礦工將其打包進新的區塊。
那麼，如果在先構建並發送了一筆從地址A發出的，nonce為11的交易，在該交易未打包進區塊之前， 再次構建一筆從A發出的交易，並將它發送到節點，不管是先通過web3的eth.getTransactionCount(A)獲取到的過往的交易數量，還是由節點自行填寫nonce， 後面的這筆交易的nonce同樣是11， 此時就出現了問題：
實際場景中，會有批量從一個地址發送交易的需求，首先這些操作可能也應該是並行的，我們不會等待一筆交易成功寫入區塊後再發起第二筆交易，那麼此時有什麼好的解決辦法呢？先來看看geth節點中交易池對交易的處理流程
如之前所說，構建一筆交易時如果不手動設置nonce值，geth節點會默認計算發起地址此前最大nonce數（寫入區塊的才算數），然後將其加上1， 然後將這筆交易放入節點交易池中的pending隊列，等到節點將其打包進區塊。
構建交易時，nonce值是可以手動設置的，如果當前的nonce本應該設置成11， 但是我手動設置成了13， 在節點收到這筆交易時， 發現pending隊列中並沒有改地址下nonce為11及12的交易， 就會將這筆nonce為13的交易放入交易池的queued隊列中。只有當前面的nonce補齊（nonce為11及12的交易被發現並放入pending隊列）之後，才會將它放入pending隊列中等待打包。
我們把pending隊列中的交易視為可執行的，因為它們可能被礦工打包進最新的區塊。 而queue隊列因為前面的nonce存在缺失，暫時無法被礦工打包，稱為不可執行交易。
那麼實際開發中，批量從一個地址發送交易時，應該怎麼辦呢？
方案一：那麼在批量從一個地址發送交易時， 可以持久化一個本地的nonce，構建交易時用本地的nonce去累加，逐一填充到後面的交易。（要注意本地的nonce可能會出現偏差，可能需要定期從區塊中重新獲取nonce，更新至本地）。這個方法也有一定的局限性，適合內部地址（即只有這個服務會使用該地址發送交易）。
說到這里還有個坑，許多人認為通過 eth.getTransactionCount(address, "pending") ，第二個參數為 pending ， 就能獲得包含本地交易池pending隊列的nonce值，但是實際情況並不是這樣， 這里的 pending 只包含待放入打包區塊的交易， 假設已寫入交易區塊的數量為20， 又發送了nonce為21，22，23的交易， 通過上面方法取得nonce可能是21（前面的21，22，23均未放入待打包區塊）， 也可能是22（前面的21放入待打包區塊了，但是22，23還未放入）。
方案二是每次構建交易時，從geth節點的pending隊列取到最後一筆可執行交易的nonce, 在此基礎上加1，再發送給節點。可以通過 txpool.content 或 txpool.inspect 來獲得交易池列表，裡面可以看到pending及queue的交易列表。
啟動節點時，是可以設置交易池中的每個地址的pending隊列的容量上限，queue隊列的上容量上限， 以及整個交易池的pending隊列和queue隊列的容量上限。所以高並發的批量交易中，需要增加節點的交易池容量。
當然，除了擴大交易池，控制發送頻率，更要設置合理的交易手續費，eth上交易寫入區塊的速度取決於手續費及eth網路的擁堵狀況，發送每筆交易時，設置合理的礦工費用，避免大量的交易積壓在交易池。
『拾』 跨行轉賬整整8天了仍未到帳，也沒退款
我們在轉賬之後，有時會出現轉賬遲遲未到賬的情況，很多用戶十分著急，甚至認為自己的幣丟失了。Tokenview收到了一封來自昵稱為港灣用戶的求助郵件。郵件中說，該用戶在進行USDT轉賬時發生了USDT丟失的情況。用戶提供了提幣地址，交易ID，接收地址以及轉賬金額和轉賬時間，問是否可以找回。
首先，我們需要先確定沒到賬的原因。一般來說，轉賬沒到賬的原因有四個：
1、地址填錯
2、網路擁堵，暫未到賬
3、確認數未達標，暫未入賬
4、手續費不足，交易被退回
我們一個個來分析。如果是第一種情況，地址填錯。地址填錯大約分二種情況，第一種情況是地址種類填錯，或者格式錯誤。這種情況下，轉賬可能無法順利進行，相應的錢包軟體會進行提示，如果交易不能發起，也就不存在丟幣的情況。但在種類填錯的情況下也不是不可能發起交易的。舉例來說，如果我們把USDT—OMNI提現到了USDT-ERC20，就會丟幣，這樣丟失的幣是無法找回的。第二種情況就是地址張冠李戴，是對應的鏈上地址，但是錯填成他人地址。這種情況交易將會順利發起，而此時交易上鏈後，基於區塊鏈不可逆的特性，任何人都無法對該筆交易進行撤回操作，除非接收方原因將幣轉回原地址。
如何判斷接收地址是否填寫錯誤呢？我們復制交易ID，或者直接復制自己的轉出地址，通過Tokenview區塊瀏覽器進行查詢。我們通過查詢該用戶提供的交易ID，可以發現，該用戶進行了火幣的一筆提現操作，其轉入地址與用戶提供的轉入地址不符，也就是說，出於某種原因，用戶將USDT轉去了錯誤的地址。
這種情況下，交易將是無法撤回的，除非改接收地址的持有人願意將這筆「天降之財」原路退回。但由於區塊鏈的匿名性，除了Tokenview標記出的交易所出入金地址及某些大戶地址外，其餘BTC、USDT地址我們是無法通過地址哈希定位其所有人的，因此可以說，在這種情況下，找回幣的幾率微乎其微。
第二種情況是網路擁堵。這種情況我們能做的就是等待交易打包上鏈。我們可以在tokenview.com的Pending交易池中看看交易是否存在。如：https://btc.tokenview.com/cn/pending。
第三種情況一般存在於交易平台充幣。當交易上鏈時，確認數為1，但由於不同交易所對確認數的要求不同，例如大部分對比特幣的確認數要求要達到6才會被確認充值成功，而以太坊則是12個。我們可以通過tokenview.com來查詢交易數。如果交易數還沒有達到要求，我們還需要再耐心等一下。
最後一種情況是手續費不足，交易被退回。這種情況交易會失敗。拿以太坊的轉賬為例，如果手續費不足，此交易將扣取手續費，並將ETH退回到轉出地址，並不存在丟幣的情況。
轉賬未到賬的幾種情況我們已經介紹完畢了。其中最關鍵的是大家在轉賬之前一定要再三確認交易地址是否填寫無誤。如果是進行USDT的轉賬，一定要確認其USDT類型。是OMNI，還是ERC20，還是TRC20，避免發生填錯類型而丟幣的意外，從而造成損失。