技术群中经常被同学问到,为什么发出的交易迟迟不被打包,我想把它给取消了,改怎么做?今天就带大家分析一下如何解决此类问题。主要分两种情况,分别有两种不同的解决方案。
nonce覆盖
以太坊中的nonce真是让人又爱又恨,恨它是因为它可以让简单的问题复杂话,在某些情况下需要自己去维护nonce值的递增性(出门右转看去微信公众号《程序新视界》查看专门讲解nonce的文章),然而它又为大家提供了一些便利的操作,比如因为较低导致交易迟迟违背打包,那么我们可以通过nonce进行覆盖。
解决方案
当我们发送一笔交易时,支付的手续费较低,导致矿工不愿意打包交易,那么此时我们该怎么办呢?这里就用到了nonce覆盖特性,同样的交易我们把手续费提高再次发送即可。需要注意的前提条件是nonce值由自己维护。
如果nonce值是让geth节点自动生成,那么再次发送时就需要构造之前交易所使用的nonce进行发送,才能达到覆盖的效果。
队列失效
问题场景
如果我们发出一笔交易,当交易迟迟未被打包,此时不想再发次笔交易,或者说想使此笔交易失效,那么该如何操作呢?比如由于程序调用导致nonce错乱,很多交易都处于队列中无法被打包,一个个进行重新发送或许不是最好的方法。
解决方案
此时如果单纯的重启节点,并不能达到清楚队列的效果,那么我们该如何操作呢?这里geth节点为我们提供了一个解决方案,那就是设置队列失效时间。
--txpool.lifetime value Maximum amount of time non-executable transaction are queued (default: 3h0m0s)
我们知道队列是存在于txpool里面的,不指定此参数值时,默认为3小时失效。那么,解决问题的方案就显而易见了,我们可以将此参数设置较小,然后重启参数,等待失效,等待txpool中交易失效之后,再改会此参数正常值,再重启项目即可。
源代码
下面我们看一下默认配置的源代码,其中包含一些其他参数的配置项:
var DefaultTxPoolConfig = TxPoolConfig{
Journal: "transactions.rlp",
Rejournal: time.Hour,
PriceLimit: 1,
PriceBump: 10,
AccountSlots: 16,
GlobalSlots: 4096,
AccountQueue: 64,
GlobalQueue: 1024,
Lifetime: 3 * time.Hour,
}
最后一行,明确说明了Lifetime为3小时。
原文链接:http://www.choupangxia.com/topic/detail/15
更多资讯
**获取更多资讯,请关注微信公众号:程序新视界。或加入QQ技术交流群:659809063。个人博客:www.choupangxia.com
本人诚接以太坊相关研发及技术支持(以太坊接口封装&代币开发等),如有需要请联系QQ:541075754。非诚勿扰。**
获得一对一技术咨询请扫码加入知识星球(小密圈)