Bubbling up errors received from the implementation contract are not decoded by Etherscan #38
Replies: 2 comments
-
Spot on analysis. Thanks a lot for investigating this, @cleanunicorn! Unfortunately, this doesn't look like it could be solved from our end. It's up to Etherscan (and the Ethereum community, at large) to coordinate over this and add the most popular custom errors to the 4byte.directory database. |
Beta Was this translation helpful? Give feedback.
0 replies
-
I am closing this as a duplicate of #36. We should keep all discussions about Etherscan over there. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
If the execution fails and returns a custom error but that error is not handled properly by Etherscan.
Consider this code that, when the execution fails and it returns an error, it will pass that error forward as the response (basically bubbling the error up).
https://github.com/paulrberg/prb-proxy/blob/a34d2771923370ea71da0fa58092ef5941e09fb8/contracts/PRBProxy.sol#L101-L109
If an error was not returned, it just emits a custom error with
revert PRBProxy__ExecutionReverted()
.The issue is that Etherscan doesn't seem to be able to identify the custom error, probably because its definition is not contained in the source code that emits the error. Thus, it seems like Etherscan doesn't have a global error database and only uses the errors defined in the source code's contract that finally emits the error (at the end of the transaction).
I've created a proof of concept deployed on Goerli.
BubbleUpError
- executes a contract and bubbles up the error in case execution fails.https://goerli.etherscan.io/address/0xda3be41216ad86036c197fb8bed53c49d2067689#code
EmitError
- emits an error when executedhttps://goerli.etherscan.io/address/0x1ff60d91652665BAdE46B4c6cD6c000564d1A2d8#code
I've tested with a transaction that emits
PRBProxy__ExecutionReverted()
. Because the error is emitted by0xda3be41216ad86036c197fb8bed53c49d2067689
and also defined in its source code, Etherscan is able to correctly decode and display it.https://goerli.etherscan.io/tx/0x34c2bf1231bf792ea42e99af71c94d09df3684223f4c4676000baff56242b5c5
When the error emitted is bubbled up from
EmitError
, Etherscan doesn't correctly decode the custom error.https://goerli.etherscan.io/tx/0x9c316b0c7b8a57698e3a38c90b1f467418e71e1a7580230105a9e2ae8740d6c5
This seems to be the case because the contract that finally returns the error doesn't have the custom error defined in its source code. It's important to note that both contracts have their source code verified, but a global error database doesn't seem to be used by Etherscan.
A second test was performed to make sure my assumption was correct.
A slightly modified contract
BubbleUpError
was deployed, but this time it also contains the same error emitted by the contractEmitError
.https://goerli.etherscan.io/address/0xf3ddca222578a6427aa7cb4dcd9af066141bc7c5#code
It seems that this time, because the error exists in the contract source code (even if it's never used directly, only bubbled up), Etherscan is able to decode it correctly.
https://goerli.etherscan.io/tx/0xff05a2d0e29e4798bc261c28383a0819773e00162fa9098a8ab935ba0cce1983
Beta Was this translation helpful? Give feedback.
All reactions