50 请教下bsc测试网，为什么批量私钥去调用薄饼合约很多出现失败。

比如五十个账户的私钥，调用他们去批量转账还好没出现什么大问题。
批量去调用薄饼接口去交易，比如三十多个号，就有十多个号失败的，大概效果就截图这样。
警告! 合约执行时遇到错误 [execution reverted ]

0220310193458422222.png

202203108888888888888888.png

循环的以下代码，单一调用转是正常的，就是批量的时候，账户少也正常，账户多了就会出现广播出去了，但是链上出现失败。大概三十多个号，出现十多个失败的。

let txData = contract.methods.swapExactETHForTokens(
		amountOutMin,
		[_this.tokens['addressB'], _this.tokens['addressA']],
		account,
		_this.getTime(600),
	).encodeABI();

	const rawTx = {
		from: account,
		to: contract.options.address,
		nonce: nonce,
		data: txData,
		value: value 
	}

	let gas = await web3js.eth.estimateGas(rawTx);
	rawTx.gas = gas;
	let signTx = await web3js.eth.accounts.signTransaction(rawTx, privateKey); 

	web3js.eth.sendSignedTransaction(signTx.rawTransaction, function(error, txHash) {}
请先 登录 后评论

最佳答案 2022-03-11 18:57

根据你这个交易的截图看，交易是因为实际使用的gas
超过了给出的gasLimit限制导致的。

之所以会出现这种情况，是因为Ethereum再估算gas消耗时，是根据当时的合约状态来计算的，但是，合约的状态是一直在变化的，引起变化的可能有多种：

  1. 将值为0的状态改变为非零，消耗2万gas。将非0改为0，会返还1.5万gas
  2. 一些循环，或者条件分支，是根据状态来确定的

上面两种，都有可能因为前面发的交易而被改变，而预估时的状态，到交易打包时已经发生变化，导致上面两种可能影响gas消耗的情概况发生，如果影响是实际gas消耗上涨，则使用原来预估时的gasLimit会导致交易失败。而这种情况在批量发交易时更容易发生，因此发生楼主描述的情况。

一种解决办法，是可以在预估gas的基础上，上调20%的变化空间。

请先 登录 后评论
默认排序 时间排序

其它 3 个回答

zen

从图上面的显示，有个gas使用率是99.23%,　先要加gaslimit　50w/100w，先排除gas的问题。

然后你这个主要问题应该是滑点，先不管是不是通缩收费的问题，　一个交易对，如果只有你一个人购买，没有其他操作，价格是每买一笔，就涨一点点，如果你的所有账号都是一个代码一起发出去的，那么后面成交的，价格已经高了，所以你的输出就达不到了。

你可以把amountOutMin写成0，你所有交易可能就通过了　　

滑点0.5
let expected = getAmountsOut();
let a = 10000 / ((0.5*100)+10000)
let b = a*expected;

b就是滑点结果

买的滑点一般是按照通缩比例就够，或者＋１，卖的话不够，得一点点往上加试试。。可能得填２倍　那种检测的没了解怎么测的，可能本地买卖一笔，拿实际额计算来的

请先 登录 后评论
左敲右滑手艺人 - 币圈慈善家

顺便问下滑点有没会计算的，买卖实际的滑点各多少，或者有没接口。我看很多地方检查合约代码安全的电报都有可以查出来滑点多少的。

以下方法算出来好像不太准，和实际薄饼上面操作出来的滑点发出去amountOutMin有偏差。不过也能发布出去。

let slippage = 20;
let amounts = await contract.methods.getAmountsOut(
	value, 
	[_this.tokens['addressB'], _this.tokens['addressA']]
).call();

let amountOutMin = toDecimal(toTransNum(amounts[1] - (amounts[1] / slippage)), 0);
请先 登录 后评论
0xluck

可能是gas给少了

请先 登录 后评论