(Feature) #1515 Gas estimation for NON-GETH nodes#1523
Conversation
|
CLA Assistant Lite All Contributors have signed the CLA. |
ESLint Summary View Full Report
Report generated by eslint-plus-action |
|
Travis automatic deployment: |
src/logic/safe/transactions/gas.ts
Outdated
| const web3 = getWeb3() | ||
| for (const additionalGasIterator of additionalGasBatches) { | ||
| try { | ||
| await web3.eth.call({ |
There was a problem hiding this comment.
Why did we remove the batch request support?
There was a problem hiding this comment.
Because for batch requests we need to use web3.eth.call.request() instead of web3.eth.call(). The first method does not returns the error as data that we need.
Responses examples:
Batch request:
Error: Returned error: Internal JSON-RPC error.
Non-batch request:
Error: Internal JSON-RPC error.
{
"code": -32015,
"message": "VM execution error.",
"data": "Reverted 0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000006457"
}
There was a problem hiding this comment.
🤔 hmmm maybe in this case we should adjust it for all ... while we might have to do 1 or 2 more request the code overhead might not be worth it.
There was a problem hiding this comment.
@rmeissner, by that you mean to get rid of the batchRequest approach?
I'm perfectly fine with that.
It's easy to follow, in the worst-case scenario we'll do 10 RPC requests (one after the other, not triggered in parallel), and the user may experiment a delay (we should think of adding something around "calculating gas..." statement somewhere, but in a different issue).
There was a problem hiding this comment.
we'll do 10 RPC requests (one after the other, not triggered in parallel)
that's because we are using await, right? if we make use of promise.all() it should not be the case, isn't it?
@fernandomg
There was a problem hiding this comment.
I think not doing them in parallel might be better here, as in most cases we will probably only need 1 or 2 requests, perform all 10 for this always would be quite some additional overhead.
There was a problem hiding this comment.
I removed the batch request and simplified the logic, now it doesn't matter which node it's running the code, the function getGasEstimationTxResponse will take care of it and return a result, then I replaced calculateGasForOpenEthereumNodes / calculateGasForGethAndNethermindNodes with the function calculateMinimumGasForTransaction. I think it's more clear now, please give it a check
src/logic/safe/transactions/gas.ts
Outdated
| const errorAsJSON = JSON.parse(error.join('')) | ||
|
|
||
| if (errorAsJSON?.data) { | ||
| const [, dataResult] = errorAsJSON.data.split('Reverted ') |
There was a problem hiding this comment.
This only works for OpenEthereum/Parity ... but not for Nethermind
There was a problem hiding this comment.
Yes you are right, I check this again and replaced non-geth comments/checks with OpenEthereum because it's the one failing. On Geth and Nethermind nodes, the initial implementation it's working (nethermind returns the result the same way as get, not as an error like openEthereum).
rmeissner
left a comment
There was a problem hiding this comment.
I would really like to see unit tests for the parsing of the error message here. (E.g. getNonGethErrorDataResult and if possible also extract the logic for the other case into a method too and test it)
|
Travis automatic deployment: |
|
Travis automatic deployment: |
src/logic/safe/transactions/gas.ts
Outdated
| const errorAsJSON = JSON.parse(error.join('')) | ||
|
|
||
| if (errorAsJSON?.data) { | ||
| const [, dataResult] = errorAsJSON.data.split('Reverted ') |
There was a problem hiding this comment.
Maybe instead if split by Reverted we split by (space), this way we also handle Nethermind (which uses revert <hex data>
There was a problem hiding this comment.
Hmmm seems they switched back .... annoying ... so we can only test this in our tests with the data from the issue ... should be enough for now :/
There was a problem hiding this comment.
I refactored the file to support nethermind and added a test case for it :)
…to feature/1515-safe-tx-estimation
src/logic/safe/transactions/gas.ts
Outdated
| } | ||
| } | ||
|
|
||
| const getOpenEthereumErrorDataResult = (errorMessage: string): string | undefined => { |
There was a problem hiding this comment.
does it make sense to move this function to a more generic place?
There was a problem hiding this comment.
I'm not sure because it will only be used here, do you have any ideas?
… gas or throws errors based on the current node
|
Travis automatic deployment: |
|
Travis automatic deployment: |
|
Travis automatic deployment: |
|
Travis automatic deployment: |
mmv08
left a comment
There was a problem hiding this comment.
Good job! It was a pleasure to review that after reading a nicely-written description, keep it up 💪
Thank you! 💪 |

Closes #1515, by:
non-gethOpenEthereum/Paritynodes errorsestimateSafeTxGasNotes:
GETH/Nethermind nodeswill return the response of the call as aresponseandOpenEthereum nodeswill always return the response as anerror, to know if the error contains a valid value we need to check if the error data contains the stringReverted <resultHash>, in that case, we known that the transaction was successful and we can extract the hash result, otherwise the transaction has failed.OpenEthereumhttps://rpc.xdaichain.com/ / https://dai.poa.network/:Post request:
Result: