ethereum / go-ethereum

Go implementation of the Ethereum protocol
https://geth.ethereum.org
GNU Lesser General Public License v3.0
47.29k stars 20.02k forks source link

solidity custom error support #26823

Open ARR552 opened 1 year ago

ARR552 commented 1 year ago

Rationale

Formerly, the only way to return a revert reason was using require(condition, ‘Something bad happened’);. The code generated by the abigen tool for a smartcontract, returned the revert reason if something was wrong. This error was triggered during the gas estimation. Now, the new way of adding custom errors (revert messages) is revert NotAllowed();. Using the code generated by the abigen, the error received is just execution reverted. I could decode the error by my own if i had access to the output data returned in the tx but this is inside the autogenerated code and not exported. I want to keep receiving the same revert reason even using the new solidity custom errors.

If this feature is already implemented, if so how can i use it??

Implementation

It should be something like this: https://blog.soliditylang.org/2021/04/21/custom-errors/

MariusVanDerWijden commented 1 year ago

I added custom error handling a while ago: https://github.com/ethereum/go-ethereum/pull/23161 However I think it only added the types and not the error unmarshaling part

smartcontracts commented 1 year ago

@MariusVanDerWijden is it correct that Geth currently doesn't surface custom revert messages in call/gas estimation?

MariusVanDerWijden commented 1 year ago

yes

smartcontracts commented 1 year ago

Got it, thank you!

n00b21337 commented 1 year ago

@MariusVanDerWijden is it correct that Geth currently doesn't surface custom revert messages in call/gas estimation?

Could you please elaborate a bit on that want to be sure. Does this mean there isn't any trace of a custom error data in hex value when we use call or gasEstimate in the response we get?

edited:

I did make a test calls over Alchemy to see what is happening and I see that in Data there is info that is signature of error so maybe you are saying that there isn't "translation" of error to human readable string? But this isnt only for call/estimates but all custom errors outputs in trx, right?

image

n00b21337 commented 1 year ago

But just plain eth_call will output nothing

image

samlaf commented 6 months ago

Are there plans to support this anytime soon? Took me a while to figure out what was happening, and seems like our only option is to revert to more gas-expensive string errors. Probably not that hard to take the 4byte error code from the data and show it as part of the error string, unless I'm missing something?

RonTuretzky commented 6 months ago

bumping this for attention

n00b21337 commented 6 months ago

Are there plans to support this anytime soon? Took me a while to figure out what was happening, and seems like our only option is to revert to more gas-expensive string errors. Probably not that hard to take the 4byte error code from the data and show it as part of the error string, unless I'm missing something?

I suppose its intended to be solved on app level, like Tenderly solves that perfectly most of the time, etherscan sadly still doesn't for some reason.

samlaf commented 6 months ago

Are there plans to support this anytime soon? Took me a while to figure out what was happening, and seems like our only option is to revert to more gas-expensive string errors. Probably not that hard to take the 4byte error code from the data and show it as part of the error string, unless I'm missing something?

I suppose its intended to be solved on app level, like Tenderly solves that perfectly most of the time, etherscan sadly still doesn't for some reason.

Are those projects even using geth abigen? We're using abigen directly and this is making us unable to use custom errors in our contracts. Unless I'm missing something when simulating transactions to estimate gas limit, there's no way right now to retrieve the error string, as its not exposed by geth.

samlaf commented 5 months ago

https://github.com/ethereum/solidity/issues/14442 just got merged. The Solidity change is specifically enabling custom errors to use with the common require(bool, err) syntax. It's a widely used syntax because it's quite concise, but until now you couldn't use error types with it so basically no one used error types. More and more teams will probably start migrating to use it, so would be really nice to have abigen support for it.

RonTuretzky commented 5 months ago

https://github.com/ethereum/solidity/issues/14442 just got merged. The Solidity change is specifically enabling custom errors to use with the common require(bool, err) syntax. It's a widely used syntax because it's quite concise, but until now you couldn't use error types with it so basically no one used error types. More and more teams will probably start migrating to use it, so would be really nice to have abigen support for it.

Bump

ypatil12 commented 3 weeks ago

Bump on this. Solidity 0.8.27 now supports custom errors in the legacy pipeline. Any timeline on support here?

cc @MariusVanDerWijden

9OP commented 1 week ago

Hello, any update on this one ? In comparison ether.js return the full data byte slice on custom error revert. It would be nice to have the same behaviour here and allow the end user to unpack the byte slice on his side.