usdt归集报错,每次都要转很多ETH,还收不到归集数据,是交易堵塞了嘛?

  • A+
所属分类:区块链

报错信息replacement transaction underpriced显示全部 

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, 此时就出现了问题:

  1. 后面的这笔交易手续费给得更高, 那么节点会前面的那笔交易从交易池中剔除,转而放入后面构建的这笔交易

  2. 如果后面的这笔交易给得不够高, 就会被废弃掉, 如果通过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.contenttxpool.inspect来获得交易池列表,里面可以看到pending及queue的交易列表。

启动节点时,是可以设置交易池中的每个地址的pending队列的容量上限,queue队列的上容量上限, 以及整个交易池的pending队列和queue队列的容量上限。所以高并发的批量交易中,需要增加节点的交易池容量。

当然,除了扩大交易池,控制发送频率,更要设置合理的交易手续费,eth上交易写入区块的速度取决于手续费及eth网络的拥堵状况,发送每笔交易时,设置合理的矿工费用,避免大量的交易积压在交易池。

发布于 2020-05-30 13:20

赞同 3添加评论

分享

收藏喜欢

收起

更多回答

usdt归集报错,每次都要转很多ETH,还收不到归集数据,是交易堵塞了嘛?

区块链老胡

楼上分析的很有道理。作为过来人,分享一个比较简单的方法,接入优盾钱包这个区块链企业钱包开放平台,usdt一键归集就可以了,最关键的是顶级私钥老板自主掌握,子私钥动态计算不触网,杜绝了黑客盗走资产的风险,踏实

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: