背景
我們在使用以太坊相關的json-rpc借口發送交易時，往往會出現這種現象：交易已經發送出去，也獲得了交易的hash值。dev模式的geth也在正常挖礦，可是問題是交易卻遲遲未被確認。會發生此種類型的接口如：
eth_sendTransaction
eth_sendRawTransaction
那么是什么原因導致此問題呢？今天就帶大家了解一些導致此問題的原因。
問題追蹤
除了上面的表象問題，我們還可以進步查詢相應的問題信息。
（1）發生上面問題的情況往往是通過json api調用或其他通過rpc調用的方式，如果直接使用控制臺（console）的命令來執行，是會被很快確認的。
（2）通過eth_getTransaction,命令我們會查詢到上面的交易，但是交易的blocknumber使用為null；
（3）通過txpool.content命名，我們會看到上面的交易處于queued隊列中，卻遲遲不會被處理。
導致以上現象的最終原因就是在發送交易時傳遞的nonce值不對。
nonce使用說明
為了防止交易的重播攻擊，每筆交易必須有一個nonce隨機數，針對每一個賬戶nonce都是從0開始，當nonce為0的交易處理完之后，才會處理nonce為1的交易，并依次加1的交易才會被處理。以下是nonce使用的幾條規則：
- 當nonce太小，交易會被直接拒絕。
- 當nonce太大，交易會一直處于隊列之中，這也就是導致我們上面描述的問題的原因；
- 當發送一個比較大的nonce值，然后補齊開始nonce到那個值之間的nonce，那么交易依舊可以被執行。
- 當交易處于queue中時停止geth客戶端，那么交易queue中的交易會被清除掉。
了解了上面的內容，大家就可以去排查自己的交易是否是因為此原因導致未成功發送了。
后語
如有問題可以留言或私下聯系。QQ技術交流群：659809063。Geth客戶端API接口封裝和智能合約調用的JAVA版本正在編寫完善，有需要的朋友也可以聯系。
