背景
我们在使用以太坊相关的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版本正在编写完善，有需要的朋友也可以联系。
网友评论