-
Notifications
You must be signed in to change notification settings - Fork 7
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
Overflow when decoding multicall transaction #50
Comments
Hey @lukerhoads, I'll have to catch up a bit since I didn't work in this project for some time. I'll take a look at your PR as soon as I can. thanks for providing the test case :) btw. |
@lukerhoads could you point me to some references about multicall? I'm not quite familiar with it. |
For sure. Sorry for not clarifying earlier. |
Hey @lukerhoads, Thanks a lot for pointing out this bug. I found out it was a problem with the decode logic for dynamic arrays (you can see it here #53, I made a regression test out of your provided test case). I made a release and included you as a contributor in it (https://github.com/FelipeRosa/rust-ethereum-abi/releases/tag/v0.3.1). I also published the new version to crates.io. Feel free to point out any related problems here or close the issue if everything is fine :) |
I encountered a similar blocking error on CoW Protocol: GPv2Settlement transaction. 'Integer overflow when casting to usize'. tx: https://etherscan.io/tx/0xaa0276520887cde6a4f1551f0ae6f7dd14db721abe209e2faf7cedbf8495284d |
Yes I think it would be useful if the decode_input_from_.. function would decode the more complex inputs fully. Like until no Bytes anymore. Because for example if I want the previously mentioned multicall to decode fully after a simple decode I have to do something like this:
Ofcourse it's looks messy and maybe not even working on every case, on some I tested worked, but it's getting complex to implement in every case, some contracts are using and different nested data. |
Test case above
For a multicall transaction, there is an
overflow when casting to usize
. I believe this is because of the check if the type is dynamic in the fixedarray match arm, but taking it away will add problems to other cases. When in the branch, it already knows the size of the array, and has already accounted for offset. I am going to try to fix this myself but might need some help :)Thanks
The text was updated successfully, but these errors were encountered: