# Solidity Language Design Community Call #0: SafeMath by Default

Below you find notes from the first Solidity language design discussion round (following up from Solidity Summit 2020). The call took place on June 3rd 2020, 5PM CEST, and aimed to collect community input on the topic of "SafeMath by Default", especially asking for feedback from auditors and Solidity developers that use SafeMath functions.

**Attendees**: Alex B, Alex D, Bhargava, Chris, Daniel, Elena D, Franzi, Goncalo (ConsenSys Diligence), Hari, Josselin (Trail of Bits), Nicolás (OpenZeppelin), Noah (Uniswap), Richard (Gnosis),

## Condensed notes:

**Main outcomes / Rough consensus on**

- overflow checks for ``+``, ``-``, ``*`` and ``/`` should be done by default
- unchecked areas to disable checks are useful
- disallow exp outside of unchecked area (unless involving constants)
- still open questions:
- on error: invalid / marked invalid / revert or marked revert
- what exactly to disable in unchecked regions

### Overview / Initial Comments

Goncalo:
checks by default also has issues - deadlocks, using it on operations that cannot overflow, ...
sometimes overflows are better than deadlocks (loops!)
have efficient tools that look for overflow, not so much or deadlocks
would not veto checks by default, though

Josselin:
go for simplicity and check overflows. Many modern languages do it. Checks by default better tradeoff for security.

Noah (Uniswap):
overflow conditions are hard to explain, explicit require statements much better. checked arithmetic by default as safety net (?)

Elena (Argent): checked everywhere for Argent, pro checked by default

Nicolas: Avoid "safe" terminology

Checks on narrowing conversion: Not clear if user would expect that, but could be helpful.

### Effect of Error condition

Josselin: Checks are used for data validation by developers. Fear of too much noise in static analysis tools if all unguarded overflows are to be flagged as "internal error".

Chris: Use "invalid" for division by zero and array out of bounds, overflow is similar internal error.

NotSureWho: Nothing gained if we want users to add guards in addition to compiler-generated checks.

Chris: Maybe use revert(sha256("ArithmeticError()")) as middle ground that is checkable by static analysis tools and thus equivalent to invalid() but does not consume all gas.

Nicolas: people will want to use unchecked areas anyway,

Noah: +1 to Nicolas, if the infix operator becomes safe by default, people might move to a specific require for custom revert reasons, given that thats the case I think an assert isn’t out of the question

Daniel: could also use invalid() plus special marker (memory write) detectable by tools

Goncalo: still like more the assertion option, it’s not hard to modify the infra to read something from memory (message)

Chris: If static analysis tools treat revert with special error message the same way we treat invalid what’s the point of having invalid? waste of gas?

### Exponentiation

Chris: No easy way to detect overflow for exp

Nicolas: haven't seen exp used a lot. if you have an exponentiation you likely have an idea what the range of your inputs are. Problem about how to communicate exp is unchecked

Alex B: we could only allow exponentiation in unchecked region

### Mechanisms of Unchecked

Chris: Which flavours of "unchecked"?

Josselin: Maybe call it "unsafe" as rust?

NotSureWhoItWas: unchecked for array access

Chris: unchecked array access and others there to save gas, but unchecked arithmetics useful if you want to have wrapping semantics. Unchecked arithmetics much safer than unchecked array access -> default to only arithmetics as unchecked, others epxplicitly

Goncalo: I also see some places where an overflow would be better than a deadlock, dl in some of the sitations is way worse than an overflow, dl will be locked forever while overflow can be corrected

## Detailed Notes

***These are rather messy notes taken during the call mostly by Franzi, excuse any mistakes or inaccuracies and feel free to edit them!***

Goncalo: SafeMath has created a lot of issues in the past for the Diligence team, especially
- deadlock conditions
- many cases where under / overflow conditions are very unlikely
- adding to the block number using SafeMath
- ...

could checked arithmetics be a solution?
tools are so far optimized to look for overflows and underflows

Josselin: Go for simplicity; uncheck operation; your compiler should be able in future to remove [...]?; better tradeoff for security is overflow check by default everywhere

Goncalo: yes, that makes sense; instead of having checked areas have **unchecked areas**; so when people don't want to have deadlocks to occur, they could use unchecked

Josseling: have unchecked operations only if users are know what they are doing

Noah (Uniswap): hard to explain to readers of smart contracts what safety conditions are being checked; to explain why it is safe with "unsafe"/overflows; special cases / unchecked to be specific and simple arithmetic by default checked

Elena (Argent Wallet): checked applies everywhere for Argent, no overflows; would be nice to have a unified checked in SafeMath in the language, pro checked by default

Nicolas: Side note on terminology: Don't call it SafeMath, it gives a wrong expectation / feeling of "safety" --> rather checked / unchecked

Josselin: add cap and uncapped operator (?)

Richard: Which bidwith is supported with SafeMath?

Chris: bitwidth question --> overflow check is performed on the higher bitwidth

Nicolás: having checks for explicit cast is helpful (?)

Josselin: people might not expect a casting operator to do this kind of check (overflow)

Nicolás: Solidity has cast in a way that C doesn't so it should be well explained, communicated and documented

Chris: Pattern:

require(x < 2**100);
require(y < 2**100);
x + y;

Are gigantic numbers being used? Asking because two possible advantages if not ...?
a) invalid opcode into revert
b) xx

Goncalo: We were asking OpenZepplin to convert reverts in safemath into assertions

Josselin: imo in most of the cases it's data validation so it should be a revert; you don't want to pay more gas for this

Chris: but in the case the overflow happens it's already an error case

Josselin: the reason you want to have the overflow by default, if they need to add a require before the operation it defeats the purpose, currently people are using SafeMath as a data validation technique;

Nicolas: What are the benefits of assertions compared to require?

Chris: assertions for division by 0; we should have the same for overflow, shouldn't we? assertions --> internal error --> people use SafeMath to validate input but its essence is an error, not an invalid input

Josselin:
example:

a - b
a.checked_sub(b, "Because ..")

Chris: generally, the overflow error that is generated by compiler should not be reachable by input, I see the point needing to add require makes contract longer, but it is cleaner

Nicolas: is that a goal for all assertions to be statically checked?

Chris: yes

Goncalo: maybe the ultimative goal would be that people can still use SafeMath (the actual OZ library) for input validation but we can still have assertions for checked arithmetics?
Then, when we'd be auditing code with SafeMath, we could see that there was intention in validating the input data (by using SafeMath functions).
All our tools behind the MythX API also use assertions to check for what should be unreachable states (static and dynamic analysis and fuzzing).

Chris: more false positives is worse than not being able to check at all?

Josselin: in practice, people will not do require before the addition; it will be more costly and more complex

Chris: yeah I can see your point; maybe the solution is to use a revert with a very specific message? can tools find this message?

Josselin: yes, tools should be able to get it

Chris: for the new code generator we're thinking of adding a z3 which is able to remove the checks

Nicolas: so then it wouldn't be more expensive anymore?

Chris: It depends, we're about to introduce different kinds of errors anyways; maybe we should introduce a special arithmetic error?

Josselin: that sounds fair

Chris: the point of invalid opcode should be detected by tools, if the message can be detected by tools too that's great and can safe gas

use revert with ArithmeticError() as middle ground?

...if we use an invalid opcode, people could safe gas in the bad path by adding ...? but that would also use up more gas in the good path, middle ground would be to have specific error message (which can be found by tools)

Nicolas: people will want to use unchecked areas anyway,

Noah: +1 to Nicolas, if the infix operator becomes safe by default, people might move to a specific require for custom revert reasons, given that thats the case I think an assert isn't out of the question

Daniel: if the main problem with invalid is creating noise in the detection tools, then we can also make those invalid's special by doing something specific before the invalid, which the tools can detect (as opposed to making it a special, detectable revert reasons)

Goncalo: for what it's worth, our tools also detect for a specific event being emitted, it would be super easy to set a standard for that too; I think I still like more the assertion option, it's not hard to modify the infra to read something from memory (message)
I just like it because it reveals intent (?)

Chris: If we treat revert with special error message the same way we treat invalid what's the point of having invalid? waste of gas?

Chris: other problem: exponentiation, we currently have no way to check overflow there, any ideas?

Goncalo: all we can do it let people know in advance and advise them? no option to get checked arithmetics there.

Chris: is it used a lot?

Nicolas: haven't seen it used a lot. if you have an exponentiation you likely have an idea what the range of your inputs are; it's inconvenient since you have to do this analysis, but it's what you need to do; exponentiation is not very common, I just worry about how to commincate that this is the only operation which has no checked arithmetics

Alex B: we could only allow exponentiation in unchecked

Nicolas: yes that makes sense!

Chris: do we want to have different flavors of unchecked, what do we want to have disabled in checked / unchecked?

Josselin: should it be called unsafe instead of unchecked? just a thought

Axic: so far only unchecked is in compiler, but unsafe vs unchecked goes more into the question whether we want to have different flavors of unchecked or not, syntax wise it would be ok but it might become just too complicated

Chris: there is a usecase for unchecked arithmetics not for saving gas when you want wrapping actions

Goncalo: I also see some places where an overflow would be better than a deadlock, dl in some of the sitations is way worse than an overflow, dl will be locked forever while overflow can be corrected

**Conclusion / Outcomes**
- checks for operators by default
- unchecked areas
- still open: what to only allow in unchecked (?)