Failed to swap on trisolaris.io

[huuducng]

Swap failed: [ethjs-query] while formatting outputs from RPC '{"value":{"code":-32603,"data":{"code":-32603,"message":"Internal Error - Exceeded the maximum amount of gas allowed to burn per contract.. Please report a bug at ","data":{"host":"mainnet.aurora.dev","cf-ray":"6a05d254758d4aa1-ORD"}}}}'

[sonlinhchu]

Swap failed: [ethjs-query] while formatting outputs from RPC '{"value":{"code":-32603,"data":{"code":-32603,"message":"Internal Error - Exceeded the maximum amount of gas allowed to burn per contract.. Please report a bug at https://github.com/aurora-is-near/aurora-relayer/issues","data":{"host":"mainnet.aurora.dev","cf-ray":"6a08e8a7e6f41949-ORD"}}}}'

[0x3bfc]

@ducpy This is an issue happening because NEAR has two separate gas limits.

• 300 Tgas per transaction
• 200 Tgas per contract

A single transaction may consist of multiple contract calls. So this means that Aurora engine contract is exceeding 200Tgas with this swap.

Is there a way to replay this swap transaction ?

[templedefi]

Trying to get some more information on this. Will the gaslimits ever be increased for contracts? It's means standard DeFi functions like addLiquidity calls to a swap router, or even zaps, don't work on Aurora.

[musecrypto]

Our yield aggregator does not seem to work because of this. Harvests revert. I would like to emphasize the severity of an issue like this on the potential defi ecosystem.

[JulianPscheid]

Ran into this issue as well while testing some contracts. If it's a design limitation with the NEAR protocol it seems like this issue might mean Aurora is dead on arrival as a DeFi platform. Can the Aurora team at least confirm that there is a roadmap to resolve this?

[qbig]

any work around for this issue?

[akshaysrivastav]

I am still facing this issue

[Doc-Failure]

me too

[netpoe]

Just got the same error increasing the Gas limit on Aurora Testnet:

transact to PaymentSplitter.setup errored: [ethjs-query] while formatting outputs from RPC '{"value":{"code":-32603,"data":{"code":-32000,"message":"Exceeded the maximum amount of gas allowed to burn per contract.","data":{"host":"r002.westcoast.us.testnet.internal.aurora.dev","cf-ray":"6f3b322d60aa9add-IAD"}}}}'

[birchmd]

@netpoe Thanks for the report! I am interested in getting more details about this transaction so that we can capture it as a benchmark that we can improve upon. Do you have the NEAR transaction hash for it by chance? It is included in the headers of the HTTP response. If not, could you describe how to reproduce the issue?

[netpoe]

@netpoe Thanks for the report! I am interested in getting more details about this transaction so that we can capture it as a benchmark that we can improve upon. Do you have the NEAR transaction hash for it by chance? It is included in the headers of the HTTP response. If not, could you describe how to reproduce the issue?

@birchmd
It's quite an expensive tx to be honest.
It's a function that accepts 2 arguments: payees: address[], shares: uint256[], and we passed 546 records to each.
This won't fail in Ropsten, for example.

We ended up modifying the contract so that it takes less records per call.

[birchmd]

Thanks @netpoe . Do you know how much gas that transaction would burn on Ethereum? Which contract has this function? Could still be worth making a benchmark in our code base so that we can track our progress towards being able to run all calls possible on Ethereum in Aurora.

[netpoe]

Thanks @netpoe . Do you know how much gas that transaction would burn on Ethereum? Which contract has this function? Could still be worth making a benchmark in our code base so that we can track our progress towards being able to run all calls possible on Ethereum in Aurora.

@birchmd it was on this Ropsten transaction: https://ropsten.etherscan.io/tx/0x8ed44ef1d0a87e0a3c309807f9c331b5e99c7c98b80ce252ce8d9c65e59503d3

It accepted 546 addresses to a whitelist in the constructor.

[birchmd]

@netpoe I was able to execute that same transaction on Aurora no problem: https://aurorascan.dev/tx/0xc4c0a89dbf14124902195389096378254821d7cd2ecc93d4858e5fa737dcab80

Is there something I'm supposed to do with that contract after I deploy it to trigger the gas error?

[soltrac]

I'm having this problem also.

My contract is: 0x1c19693ead3654f7ddc9b4a3163a6ac7a72cb47c

The input is:

0x5719bfd30000000000000000000000004b218d86b47d596aabfbd33f3d997d41d95f61fd00000000000000000000000010a9153a7b4da83aa1056908c710f1aaccb3ef8500000000000000000000000030fff4663a8dcdd9ed81e60acf505e6159f19bbc000000000000000000000000bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb000000000000000000000000a195b3d7aa34e47fb2d2e5a682df2d9efa2daf060000000000000000000000000000000000000000000000000000007f2abf620a

How much maximum ETH Gas should we consider in a transaction? This transaction is using more than 1.000.000 of gas, that's sure.

[birchmd]

Thanks for the report @soltrac . I attempted to reproduce the max gas error by calling the contract with the input you provided, but the transaction reverted with error message has liquidity (see https://aurorascan.dev/tx/0x4ed34150db33f6e68e7149c5e2000ee97e28dd8fe10158f7a8ea881612ceb2e0 and https://explorer.mainnet.near.org/transactions/DKqsJcNiwrHNedbEiozdUkgUGEhNKqvmaFpYc6t63WVD )

Is there a way I can reproduce the gas limit error myself using your contract?

[soltrac]

No sorry, it was a call that was working in that moment only. The only thing that I can say that in that contract, if I use more than 1.000.000 of gas, the call is reverted. If not, it goes ok.

[birchmd]

Could you tell me more about what this contract is doing @soltrac ? We are always working on improving the Engine efficiency to prevent transactions from hitting the gas limit. It would be good if we could capture your use case as a benchmark. Then we could track our progress as we push new optimizations. The easiest way we can create a benchmark is to reproduce a real transaction (see this for example), so if you could get your contract back into a state where it will reliably hit the gas limit I could perform the transaction and capture it as a benchmark.

[soltrac]

It is difficult because the contract is liquidating an operation on https://lending.auroraswap.net/, so it is only available when a liquidation can be done. It makes a flashloan on a dex, liquidates the operation there (that is a COMPOUND protocol fork) and after that, makes a swap an returns the flasloan.

As you can see, it is complex and very difficult to reproduce it, because not always liquidations are open.

[birchmd]

Thanks for the description @soltrac . How were you able to work around the gas limit issue when you encountered it in the previous liquidation?

[soltrac]

Those liquidations just needed less than 1m gas, so they just worked. The moment they are a little more complex (I suppose the liquidation part of the contract does more things in some cases), I need more than 1m of gas and the execution is reverted.

The liquidation part must be very similar to this one:

https://github.com/CreamFi/compound-protocol/blob/master/contracts/CErc20.sol#L109

[birchmd]

@soltrac what I meant was, in the case you reported where you hit the gas limit during a liquidation, how did you get the contract back to a good state again? Why is it not still stuck trying to do a liquidation that does not fit in the gas limit?

[soltrac]

I really don't understand the question, maybe is my English. If I cannot do that liquidation, I cannot do it ever. Other liquidations are possible because I don't hit that gat limit, for example:

https://aurorascan.dev/tx/0xe6de4fae2b091cbb8c6443f8d95e9ee70d7e7e1d028b4f7e742f59c5f5930e0b

[birchmd]

Sorry, let me try to be more clear @soltrac . In this comment you reported hitting the gas limit. And in this comment you said the operation hitting the gas limit is a liquidation. But I was not able to reproduce hitting the gas limit and you say this is because there is no liquidation to do. So something must have changed to allow the liquidation to complete or no longer be required, and I am wondering what that could have been. If you were able to work around the gas limit issue this could be useful information for others.

[soltrac]

Ahhh. Yes, maybe other user liquidated that position, maybe the user to liquidate added more collateral and its position could not be liquidated anymore, maybe he repaid his debt. The thing is that right now that position is not liquidable. It is very common.

[birchmd]

I see, thanks for the clarification @soltrac . So this was not working around the gas limit issue really. The user in question still got to cheat the system in some sense because they should have been liquidated, but instead they got the chance to correct their position instead.

In any case, please post here next time you encounter this issue. I will try to react to it quickly enough to capture it as a benchmark next time.

[acryptosx]

Could you tell me more about what this contract is doing @soltrac ? We are always working on improving the Engine efficiency to prevent transactions from hitting the gas limit. It would be good if we could capture your use case as a benchmark. Then we could track our progress as we push new optimizations. The easiest way we can create a benchmark is to reproduce a real transaction (see this for example), so if you could get your contract back into a state where it will reliably hit the gas limit I could perform the transaction and capture it as a benchmark.

@birchmd Here is a transaction that would (currently) hit the gas limit: https://aurorascan.dev/tx/0xe238ad08ab58d3f654bf6a2c8de4f867f3f1fa5633c7faa3245d23709d9fe20c
(call harvest() to 0xe29a236d38f609fa7891851a0828c8b9dd197f6e)

Is there any way to workaround it or we just have to find a way to reduce the gas usage of our contract?

[birchmd]

Thanks for the report @acryptosx !

I was able to reproduce the gas limit error by simply calling harvest on that contract as you said. This is the corresponding transaction on NEAR. I can use this to make a benchmark on the Engine as I have done with other transactions (example).

For now, I can say that you're exceeding the gas limit by about 30%. There is an update to the engine coming soon which improves the gas efficiency of the engine by about 20%, so not quite enough for your transaction. In the short term, I recommend trying to have your contract consume less gas. But in the medium/long term, I think future engine optimizations will make it so that this kind of transaction will pass.

[acryptosx]

@birchmd is there any way to test if transactions will go through or not using a mainnet fork on hardhat network? Or do I just have to try it on mainnet?

[acryptosx]

@birchmd unfortunately this issue is a blocker for us deploying on Aurora, hopefully it gets resolved and we can revisit in the future.

[birchmd]

@acryptosx

is there any way to test if transactions will go through or not

Currently you must try on mainnet. However we are working on a gas estimation tool that will allow for local testing.

this issue is a blocker for us deploying on Aurora

Sorry to hear this. There is a new NEAR protocol upgrade coming at the end of May which should improve the situation substantially. So you may want to try again in June. And of course we will continue to improve on this issue going forward; I hope eventually we will be able to support your project.