Skip to content

Handle abi decoding failures when unpacking revert reason in EVM #3419

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

bhartnett
Copy link
Contributor

No description provided.

var reasonCode: UInt256
discard decode(data.toOpenArray(4, data.len() - 1), 0, 0, reasonCode)
assign(reason, panicReasons.getOrDefault(reasonCode.truncate(int)))
try:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to come up with our own decode functions instead of relying on web3 decoder.
We also try to eliminate exception from EVM, except for unavoidable cases. But in this case I think we can avoid exception.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well the abi decoding is not trivial to implement so I'd rather not spend time on writing my own abi decoder. This web3 implementation does work but it just turns out that it doesn't handle failure scenarios very well and so it can throw Defect if the input is not valid abi.

I think using this implementation is fine since nimbus-eth1 already depends on nim-web3. Now if the reason for wanting to eliminate exceptions from the EVM is performance then I'll move this outside the EVM.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Catching Exception isn't well-defined in Nim, so can't be relied on anyway.

This needs to be fixed in nim-web3, or, yeah, nim-web3 bypassed in this case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then I will offer my alternatives

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes agreed.

For now, I've moved the usage of unpackRevertReason outside the EVM since, as far as I'm aware, this is only needed by EVM calls used by the RPC endpoints anyway.

Also now catching a Defect to be more specific. Added a comment to explain the reasoning and also will make a note to do a separate PR in nim-web3 to improve the error handling in the library.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's precisely Defect that is unreliable to catch (and by extension Exception since it might be a Defect) .. ergo, it should be avoided here.

Instead of returning a decoded string reason, could return the raw bytes do the decoding elsewhere though no matter where it's done, a Defect should never be raised (ie this must be fixed by fixing the decoder not to raise a defect or by pre-checking the values)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants