replacement transaction underpriced异常
问题概述
以太坊系列（ETH&ETC）在发送交易有三个对应的RPC接口，分别是ethsendTransaction、ethsendRawTransaction和personal_sendTransaction。这三个接口发送（或构造发送内容时）都需要一个参数nonce。官方文档对此参数的解释是：整数类型，允许使用相同随机数覆盖自己发送的处于pending状态的交易。
仅从官网的解释，我们无法获取到更多的有效的信息。但在真实生成中我们会发现如果传错nonce字段值，通过RPC接口调用发送的交易很大可能将不会被确认。如果通过console命令来操作一般不会出现此问题，因为节点已经帮我们处理了。
如果继续追踪问题，会发现nonce传递错误的交易可以通过eth_getTransaction查询得到相关信息，但是它的blocknumber始终未null，也就说这边交易始终未被确认。如果是在dev模式下，应该是很快就会被确认的。更进一步，通过txpool.content命令，会发现那笔交易一直处于queued队列中，而未被消费。
在使用同一个地址连续发送交易时，每笔交易往往不可能立即到账， 当前交易还未到账的情况下，下一笔交易无论是通过eth.getTransactionCount()获取nonce值来设置，还是由节点自动从区块中查询，都会获得和前一笔交易同样的nonce值，这时节点就会报错Error: replacement transaction underpriced
为了防止交易重播，ETH（ETC）节点要求每笔交易必须有一个nonce数值。每一个账户从同一个节点发起交易时，这个nonce值从0开始计数，发送一笔nonce对应加1。当前面的nonce处理完成之后才会处理后面的nonce。注意这里的前提条件是相同的地址在相同的节点发送交易。 以下是nonce使用的几条规则：
● 当nonce太小（小于之前已经有交易使用的nonce值），交易会被直接拒绝。
● 当nonce太大，交易会一直处于队列之中，这也就是导致我们上面描述的问题的原因；
● 当发送一个比较大的nonce值，然后补齐开始nonce到那个值之间的nonce，那么交易依旧可以被执行。
● 当交易处于queue中时停止geth客户端，那么交易queue中的交易会被清除掉。
如果系统中的热点账户或普通账户发起交易时出现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%。
经过上面的解释追踪，我们已经了解到了nonce的基本使用规则。那么，在实际应该用中我们如何保障nonce值的可靠性呢？这里有两个思路，第一个思路就是由业务系统维护nonce值的递增。如果交易发送就出现问题，那么该地址下一笔交易继续使用这个nonce进行发送交易。第二个思路就是使用现有的api查询当前地址已经发送交易的nonce值，然后对其加1，再发送交易。对应的API接口为：eth_getTransactionCount，此方法由两个参数，第一个参数为需要查询nonce的地址，第二个参数为block的状态：latest、earliest和pending。一般情况使用pending就可以查询获得最新已使用的nonce。其他状态大家可以自行验证。
如果该热点账户的私钥信息等都存放在Ethereum客户端中，那么在发送交易的时候不传递nonce值，Ethereum客户端会帮你处理好此nonce值的排序。
当然，此方案有两个弊端。第一个是安全性无法保障（未进行冷热账户分离），第二，在热点账户下如果想覆盖掉一笔交易，需要先查询一下该交易的信息，从中获取nonce值。
自行管理nonce适用于冷热账户模式，也就是适用sendRawTransaction发送已经签名好的交易时，此时nonce值已经存在于交易中，并且已经被签名。
这种模式下，需要在业务系统中维护nonce的自增序列，适用一个nonce之后，在业务系统中对nonce进行加一处理。
此种方案也有限制条件。第一，由于nonce统一进行维护，那么这个地址必须是内部地址，而且发起交易必须通过统一维护的nonce作为出口，否则在其他地方发起交易，原有维护的nonce将会出现混乱。第二，一旦已经发出的交易发生异常，异常交易的nonce未被使用，那么异常交易的nonce需要重新被使用之后它后面的nonce才会生效。
在构建一笔新的交易时，在交易数据结构中会产生一个nonce值， nonce是当前区块链下，发送者(from地址)发出的交易(成功记录进区块的)总数， 再加上1。例如新构建一笔从A发往B的交易，A地址之前的交易次数为10，那么这笔交易中的nonce则会设置成11， 节点验证通过后则会放入交易池（txPool）,并向其他节点广播，该笔交易等待矿工将其打包进新的区块。
那么，如果在先构建并发送了一笔从地址A发出的，nonce为11的交易，在该交易未打包进区块之前， 再次构建一笔从A发出的交易，并将它发送到节点，不管是先通过web3的eth.getTransactionCount(A)获取到的过往的交易数量，还是由节点自行填写nonce， 后面的这笔交易的nonce同样是11， 此时就出现了问题：
- 后面的这笔交易手续费给得更高， 那么节点会前面的那笔交易从交易池中剔除，转而放入后面构建的这笔交易
- 如果后面的这笔交易给得不够高， 就会被废弃掉， 如果通过web3这样的sdk来向节点发送交易时，会收到错误信息
实际场景中，会有批量从一个地址发送交易的需求，首先这些操作可能也应该是并行的，我们不会等待一笔交易成功写入区块后再发起第二笔交易，那么此时有什么好的解决办法呢？先来看看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网络的拥堵状况，发送每笔交易时，设置合理的矿工费用，避免大量的交易积压在交易池。