I chose solc 0.8.4 and upgraded contracts to v4 for a project which previously used solc 0.7.6 + SafeMath.
If I leave the (v4) SafeMath function in place, do I actually double check and burn double gas ?
Xuser
June 3, 2021, 11:05am
2
The safemath version that you can add to the upgrade is available at the link below. It would be appropriate to upgrade to the version that works with 8.4.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
// CAUTION
// This version of SafeMath should only be used with Solidity 0.8 or later,
// because it relies on the compiler's built in overflow checks.
/**
* @dev Wrappers over Solidity's arithmetic operations.
*
* NOTE: `SafeMath` is no longer needed starting with Solidity 0.8. The compiler
* now has built in overflow checking.
*/
library SafeMath {
/**
* @dev Returns the addition of two unsigned integers, with an overflow flag.
*
* _Available since v3.4._
*/
show original
If you have already upgraded to this version and are still worried; No need to worry. Safety is more important than gas. If you upgrade to the above version, the answer to your question is; unless there is an unusual condition for soundness 8.4; I don’t think your project will spend twice as much for gas. I wish you success in your project.
Sorry for the noob question. If I am not wrong from 0.8.0 Safemath is no needed anymore. So do you advice to still use it or no?
1 Like
wondering the same thing as FreezyEx, 0.8+ versions prevent overflow/underflow, so is using SafeMath a good practice now?
In Solidity 0.8 SafeMath is no longer needed. It remains in OZ Contracts v4 as a no-op to ease migration to the new version. See the relevant discussion in this issue:
opened 07:18PM - 08 Jan 21 UTC
closed 01:49PM - 10 Feb 21 UTC
There has been some discussion in https://github.com/OpenZeppelin/openzeppelin-c… ontracts/pull/2442 on whether to keep or remove `SafeMath` from the Solidity 0.8 release of the library. We don't seem to have consensus yet so I would like to continue the discussion and explore the arguments that are being made.
The origin of the discussion is that Solidity 0.8 includes checked arithmetic operations by default, and this renders `SafeMath` unnecessary. What is not under discussion is that internally the library will use the built in checked arithmetic, rather than the current manual overflow checks in `SafeMath`. The question is whether we want to keep `SafeMath` for other reasons.
#### Backwards compatibility
It may be better to keep `SafeMath` to ease the transition from Contracts 3.x (Solidity 0.6-0.7) to Contracts 4.x (Solidity 0.8). If we remove it, users who update will be flooded with error messages that they will have to fix before they do anything else. They may want to try other interesting things in Solidity 0.8, and/or remove `SafeMath` progressively (for example making sure their tests continue to pass during the migration).
@axic's counterargument:
>Perhaps it is better biting the bullet by removing it, and that could trigger users to review the new semantics and use them properly (checked vs. unchecked). And also be aware of the gas implications.
It's true that using `SafeMath` function calls will be more expensive than just built in arithmetic. The idea would be that users should remove `SafeMath` once they're using Solidity 0.8. But should we force people to do this migration as soon as they jump on Solidity 0.8? If there was a way to _nudge_ them, such as a deprecation warning, I would agree that we should do it, but removing `SafeMath` entirely is a lot stronger and causes what seems like unnecessary breakage.
#### Use inside `unchecked` blocks
@Amxx [mentions](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/2442#issuecomment-754551003) that `SafeMath` would be a way to insert checked operations inside `unchecked` blocks. This is an interesting idea. If we think this is a genuine use case it would not make sense to deprecate `SafeMath`.
Several people seem to have reacted against this proposal and it would be great to hear more from them. (@mlntr @cruzdanilo @hrkrshnn @stvndf)
---
Personally I think we should keep the wrapper for backwards compatibility only, deprecated and planned to be removed in the next major release. This is motivated by an intention to keep breaking changes to a minimum. Even if we do not remove it, we can communicate this deprecation clearly and recommend users to refactor their code to remove `SafeMath` once they migrate to 0.8.
Leaving SafeMath in v4 will not check for overflow twice, so it will not burn double gas. Although there may be a small overhead if the compiler doesn't optimize the function call away.