㈠ 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網路的擁堵狀況，發送每筆交易時，設置合理的礦工費用，避免大量的交易積壓在交易池。
㈡ 以太坊區塊鏈之Bug --2020/05/19
為了防止交易重播，ETH（ETC）節點要求每筆交易必須有一個nonce數值。每一個賬戶從同一個節點發起交易時，這個nonce值從0開始計數，發送一筆nonce對應加1。當前面的nonce處理完成之後才會處理後面的nonce。注意這里的前提條件是相同的地址在相同的節點發送交易。
以下是nonce使用的幾條規則：
● 當nonce太小（小於之前已經有交易使用的nonce值），交易會被直接拒絕。
● 當nonce太大，交易會一直處於隊列之中，這也就是導致我們上面描述的問題的原因；
● 當發送一個比較大的nonce值，然後補齊開始nonce到那個值之間的nonce，那麼交易依舊可以被執行。
● 當交易處於queue中時停止geth客戶端，那麼交易queue中的交易會被清除掉。
第一個欄位 AccountNonce ，直譯就是賬戶隨機數。它是以太坊中很小但也很重要的一個細節。以太坊為每個賬戶和交易都創建了一個Nonce，當從賬戶發起交易的時候，當前賬戶的Nonce值就被作為交易的Nonce。這里，如果是普通賬戶那麼Nonce就是它發出的交易數，如果是合約賬戶就是從它的創建合約數。
為什麼要使用這個Nonce呢？其主要目的就是為了防止重復攻擊（Replay Attack）。因為交易都是需要簽名的，假定沒有Nonce，那麼只要交易數據和發起人是確定的，簽名就一定是相同的，這樣攻擊者就能在收到一個交易數據後，重新生成一個完全相同的交易並再次提交，比如A給B發了個交易，因為交易是有簽名的，B雖然不能改動這個交易數據，但只要反復提交一模一樣的交易數據，就能把A賬戶的所有資金都轉到B手裡。
當使用賬戶Nonce之後，每次發起一個交易，A賬戶的Nonce值就會增加，當B重新提交時，因為Nonce對不上了，交易就會被拒絕。這樣就可以防止重復攻擊。當然，事情還沒有完，因為還能跨鏈實施攻擊，直到EIP-155引入了chainID，才實現了不同鏈之間的交易數據不兼容。事實上，Nonce並不能真正防止重復攻擊，比如A向B買東西，發起交易T1給B，緊接著又提交另一個交易T2，T2的Gas價格更高、優先順序更高將被優先處理，如果恰好T2處理完成後剩餘資金已經不足以支付T1，那麼T1就會被拒絕。這時如果B已經把東西給了A，那A也就攻擊成功了。所以說，就算交易被處理了也還要再等待一定時間，確保生成足夠深度的區塊，才能保證交易的不可逆。
Price 指的是單位Gas的價格，所謂Gas就是交易的消耗，Price就是單位Gas要消耗多少以太幣（Ether），Gas * Price就是處理交易需要消耗多少以太幣，它就相當於比特幣中的交易手續費。
GasLimit 限定了本次交易允許消耗資源的最高上限，換句話說，以太坊中的交易不可能無限制地消耗資源，這也是以太坊的安全策略之一，防止攻擊者惡意佔用資源。
Recipient 是交易接收者，它是common.Address指針類型，代表一個地址。這個值也可以是空的，這時在交易執行時，會通過智能合約創建一個地址來完成交易。
Amount 是交易額。這個簡單，不用解釋。
Payload 比較重要，它是一個位元組數組，可以用來作為創建合約的指令數組，這時每個位元組都是一個單獨的指令；也可以作為數據數組，由合約指令來進行操作。合約由以太坊虛擬機（Ethereum Virtual Machine，EVM）創建並執行。
V、R、S 是交易的簽名數據。以太坊當中，交易經過數字簽名之後，生成的signature是一個長度65的位元組數組，它被截成三段，前32位元組被放進R，再32位元組放進S，最後1個位元組放進V。那麼為什麼要被截成3段呢？以太坊用的是ECDSA演算法，R和S就是ECSDA簽名輸出，V則是Recovery ID。
R,S,V是交易簽名後的值，它們可以被用來生成簽名者的公鑰；R，S是ECDSA橢圓加密演算法的輸出值，V是用於恢復結果的ID
㈢ 如何讓以太坊歸零
讓以太坊歸零不是一個可行的操作。因為以太坊是一種去中心化的區塊鏈網路，所有的交易記錄和智能合約的執行結果都被永久記錄在區塊鏈上，不可篡改。這也是以太坊的安全性和可靠性弊叢握的來源之一。
因此，如果想要清空以太坊賬戶的余額，只能通過將賬戶中的以太幣轉移到其他地址或銷毀以太幣來實現。這個過程需要進行交易，並且需要支付交易費用。
需要注意的是，以太坊的交易費用是以 Gas（燃料）為單位計算的，每個操作都需要消耗租慶一定的 Gas。因此，在進行轉賬或銷毀以太幣時，需要考慮到 Gas 的消耗，以確保交易能夠被正常執行。
總之，讓以太坊歸零是不可能的，只能通過轉移或銷毀以太幣來實現清空賬戶的余額。在進行這個過程時，需要注意到交易鄭絕費用和 Gas 的消耗。
㈣ 以太坊轉賬流程
發起:用戶在本地的以太坊錢包軟體中選擇要發送的交易地址(From)、輸入目標地址(To)、金額(Value)、是否部署或調用合(Data)、手續費單價(Gasprice)等,確認發送至以太坊節點節點和錢包可以是同一台
廣播:節點收到(或自己發起)交易後,會對交易進行驗證。驗證:交易的簽名、發起賬號的余額是否能支付轉賬余額與手續費、Nonce是否為賬號已發出的交易數。驗證為合法後,將交易加入節點的交易池中交易池中存儲著待打包的交
安裝以太坊瀏覽器錢包插件,創建錢包,獲取虛擬以太幣,進行轉賬交易。 實驗內容 學習 初識以太坊,發送交易 1.學習《初始以太坊,發送交易》,虛擬以太幣交易。
㈤ 以太坊錢包不更新
網路不順暢或其它。
節點同步慢原因以及解決方法：1、以太坊錢包節點同步需要聯網操作，如果你的網路不暢通就會造成同步慢這種情況，所以在同步之前請檢查好你的網路，確認網路狀況良好在進行同步。2、節點同步需要佔用大量的內存，如果你的電腦內存不夠就會造成階段同步慢甚至停止同步這種情況，建議用戶在同步節點之前清理一下電腦保證電腦內存充足，目前有用戶反映同步節點內存最高可佔用100G左右內存哦。3、可以在以太坊錢包中修改peer數，默認peer是25個，建議你可以修改成巨大的數值，例如9999個。4、同步階段還需要你的路由器支持uPnP。可以在路由器設置中修改。5、需要公網IP，如果你沒有的話就會慢很多，所以建議設置一個公網IP吧。6、也有網友反映是錢包本身的問題，以太坊錢包軟體本身並不是很成熟，在同步節點的時候會有很多問題出現，這個只有等待以太坊官方修改。7、電腦配置不能太低。8、第一次同步時使用--fast選項，可以更快地同步到最新塊。9、使用的是geth，運行時間長了可能會有問題，可以考慮每天重啟一次geth。10、及時更新geth到最新版本。11、硬碟空間要足夠大，建議至少1T以上。為了運行以太坊全節點，買了500G的硬碟空間，使用--fast同步完成後才佔40多G空間，之後正常模式同步硬碟佔用空間快速增長，3個月左右已經430G了，最近又買了500G磁碟空間。12、交易未被打包時，相同nonce值可以覆蓋之前的交易，覆蓋交易只看nonce值，至於交易的其它部分內容可以相同也可以不同。13、如果有低nonce值還未被打包，新的交易gasPrice再高，也需要先等低nonce值的交易被打包，如果低nonce值的交易因為gasPrice設低了而等待，需要先使用相同nonce值來修改gasPrice。
以太幣（ETH）是以太坊的一種加密數字代幣，被視為「比特幣2。0版」，創始人是傑弗里_維爾克。