-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
Option to specify opcode for require/assert exceptions #2586
Comments
The documentation may need some rewording/refactoring (that particular block is quite chunky), but the idea is the following: Insert hard assertions into the code before critical parts (such as overflows, transfers, etc.). Additionally, guard the code with This can be easily detected via outside testing tools (i.e. truffle/dapple/etc.). Once ethereum/interfaces#1 or ethereum/interfaces#8 is implemented, the execution result (success, failure or revert) should be easily distinguishible. Furthermore, analyzers should be able to point to unchecked conditions and perhaps in the future assertions could be optimised out for conditions already covered by |
Big 👍 for this. Personally, I understand and value how this is supposed to ease the development of formal verification tools for Solidity code but it appears to me it would make more sense to use the Maybe there is some obvious reason I'm missing as to why this is engineered this way? EDIT: Just missed the answer above while typing. @axic is it possible that this is going to promote some waste of gas? I get where you're coming from but this is a huge trade-off. Maybe this should be done at the protocol level? Something like making |
This is quite helpful, thank you. Would it be accurate to say then that if tests are causing |
Yes, if anything can cause |
Looking again, this is clear "If this is possible, this means there is a bug in your contract you should fix.", though not as emphatic as I think it should be for such an important distinction. Generally, from the perspective contract designer, it feels difficult to differentiate between the exact instances when one should be:
|
Rather than just go back and forth, how does this look? The main change is expanding on the cases which should use |
Can this be closed now? |
FWIW, there is still a lot of confusion in the field about Maybe you could tweet one of your solidity tips. :) |
Not sure if the tweet will help, but tried it anyway :-) |
Yes, I think that would be really valuable! |
What about guarding against overflow/underflow as in this case? |
@maurelian we are currently working on a static analyzer for that: #2538 |
Can you just clarify that, for current popular use of (Sorry for being a pin in the ass, just trying to get this really right 😄) |
@GNSPS my opinion is that you should not just throw an exception on overflow, because the fact that at overflow was possible usually means that you did not think of some of the edge cases, and furthermore, throwing an exception might forever stall some process. For example, take the following code (from ENS) - perhaps not the best example:
If you just checked for underflow in |
It appears to me that further separation of concerns between
require()
andassert()
would be helpful. From the documentation:This is of course a reference to ethereum/EIPs#140, and the new
REVERT
opcode. In this case the choice between the two is at a lower level than the source code.This is a completely distinct use case, which I believe is a static analysis concern), above the source code level.
I'm not sure what if anything the advantages of an
invalid opcode
exception would be, but I think it would be helpful to be able to throw an internal error AND have the benefits ofREVERT
(gas refunds + pass a return value).It's possible the issue title is overly prescriptive, there might be a better way to resolve this.
The text was updated successfully, but these errors were encountered: