为了防止交易重播，ETH（ETC）节点要求每笔交易必须有一个nonce数值。每一个账户从同一个节点发起交易时，这个nonce值从0开始计数，发送一笔nonce对应加1。当前面的nonce处理完成之后才会处理后面的nonce。注意这里的前提条件是相同的地址在相同的节点发送交易。以下是nonce使用的几条规则：● 当nonce太小（小于之前已经有交易使用的nonce值），交易会被直接拒绝。● 当nonce太大，交易会一直处于队列之中，这也就是导致我们上面描述的问题的原因；● 当发送一个比较大的nonce值，然后补齐开始nonce到那个值之间的nonce，那么交易依旧可以被执行。● 当交易处于queue中时停止geth客户端，那么交易queue中的交易会被清除掉。
获取nonce值
经过上面的解释追踪，我们已经了解到了nonce的基本使用规则。那么，在实际应该用中我们如何保障nonce值的可靠性呢？这里有两个思路，第一个思路就是由业务系统维护nonce值的递增。如果交易发送就出现问题，那么该地址下一笔交易继续使用这个nonce进行发送交易。第二个思路就是使用现有的api查询当前地址已经发送交易的nonce值，然后对其加1，再发送交易。对应的API接口为：eth_getTransactionCount，此方法由两个参数，第一个参数为需要查询nonce的地址，第二个参数为block的状态：latest、earliest和pending。一般情况使用pending就可以查询获得最新已使用的nonce。其他状态大家可以自行验证。
replacement transaction underpriced异常
如果系统中的热点账户或普通账户发起交易时出现error: replacement transaction underpriced异常，那么就需要考虑nonce使用是否正确。
引起此异常原因主要是当一个账户发起一笔交易，假设使用nonce为1，交易已经发送至节点中，但由于手续费不高或网络拥堵或nonce值过高，此交易处于queued中迟迟未被打包。
同时此地址再发起一笔交易，如果通过eth_getTransactionCount获取的nonce值与上一个nonce值相同，用同样的nonce值再发出交易时，如果手续费高于原来的交易，那么第一笔交易将会被覆盖，如果手续费低于原来的交易就会发生上面的异常。
通常发生此异常意味着：
- 你的Ethereum客户端中已经有一币处于pending状态的交易。
- 新的一笔交易拥有pending状态交易相同的nonce值。
- 新的交易的gas price太小，无法覆盖pending状态的交易。
通常情况下，覆盖掉一笔处于pending状态的交易gas price需要高于原交易的110%。
针对此问题在不同的使用场景下有不同的解决方案。
依赖钱包
如果该热点账户的私钥信息等都存放在Ethereum客户端中，那么在发送交易的时候不传递nonce值，Ethereum客户端会帮你处理好此nonce值的排序。
当然，此方案有两个弊端。第一个是安全性无法保障（未进行冷热账户分离），第二，在热点账户下如果想覆盖掉一笔交易，需要先查询一下该交易的信息，从中获取nonce值。
自行管理nonce
自行管理nonce适用于冷热账户模式，也就是适用sendRawTransaction发送已经签名好的交易时，此时nonce值已经存在于交易中，并且已经被签名。
这种模式下，需要在业务系统中维护nonce的自增序列，适用一个nonce之后，在业务系统中对nonce进行加一处理。
此种方案也有限制条件。第一，由于nonce统一进行维护，那么这个地址必须是内部地址，而且发起交易必须通过统一维护的nonce作为出口，否则在其他地方发起交易，原有维护的nonce将会出现混乱。第二，一旦已经发出的交易发生异常，异常交易的nonce未被使用，那么异常交易的nonce需要重新被使用之后它后面的nonce才会生效。