Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Another attempt on SafeMath assert->require but for a different reason #1120
The different reason is the formal verification module we're building in Solidity. I'll start with a general argument from my side, then I'll talk about the FV module.
I've read the multiple discussions in different issues/PRs, and first of all I need to say that I do disagree with having asserts in SafeMath. What the code does is filtering inputs, therefore requires should be used.
Assuming that users do not filter their input and rely on SafeMath to guarantee no underflows/overflows, this breaks formal verification. The reason is that the verifier sees no filtering (no assumptions on the input), and then sees the assertion
So, from a verification perspective it would also make more sense to have
I'd love to hear your thoughts on it, even though it's a repetitive discussion...
referenced this issue
Jul 27, 2018
One simple example could be:
Of course this is a very simple example, but it illustrates that the invariant
Another simple example:
Similarly, the assertion should be true regardless the state of the whole thing.
Another more complex example would be, that after sorting an array, you could assert for each position that the element is
Summary: conditions in
So I think in the end it kinda comes down to what's expected from the user, and what should the user expect from SafeMath.
From a practical verification point of view: if
We're also playing with verification and moving the assert -> requires seems like the right thing to do (or at least if would be very helpful). Since the semantics are the same modulo gas, it's more about intent.
For verification purposes we treat
The intent doe SafeMath is more in line with "let's assume that this holds" and use it (and if doesn't hold, it's OK due to revert). Considering the amount of contracts using SafeMath this is a big deal for verification attempts since, in most cases, it's not hard to trigger the overflows and these would then be reported as bugs (while they shouldn't).
I see what you mean and agree with the raised points. Would
referenced this issue
Jul 30, 2018
I just found a curious situation in #915, where an
I worry other tools may be taking the same approach, leading to issues due to different interpretations on the semantics of
In my opinion they got
I see your point about a consistent interpretation of asserts throughout the projects. I'm not aware of other projects interpreting asserts like that, even though they probably exist.