[x/programs] Utilize safe math for programs

[exdx]

Arithmetic operations in smart contracts require usage of a "safe math" library to prevent overflows and underflows.

There are well supported safe math libraries in Ethereum.

It should be clear that an overflow is an error that is handled gracefully. Both the NFT and token program are currently vulnerable to overflows.

[richardpringle]

I don't think we need a safe-math library. Rust has all the saturating_*/checked_* functions built-in and also has a much more powerful type system (NonZero* types, for example). It doesn't make sense just to wrap methods and types that already exist in std.

It might be more beneficial to gently guide hyper-program developers to fuzz and/or prop-testing their public methods, such that they realize which std types and methods they need to use to prevent overflows/underflows, etc.

[patrick-ogrady]

I don't think we need a safe-math library. Rust has all the saturating_/checked_ functions built-in and also has a much more powerful type system (NonZero* types, for example). It doesn't make sense just to wrap methods and types that already exist in std.

IMO we should use Rust-native functionality wherever possible. We should optimize for as minimal of a cognitive leap as required to go from Rust to writing HyperSDK Programs. The nice byproduct of this is that it reduces the size of the codebase we need to maintain.

[exdx]

Apparently in in solidity 0.8.0+ any integer overflows or underflows automatically cause the transaction to revert. Maybe panicking on case of an overflow is the best solution?

[exdx]

My understanding is that in debug mode Rust will panic but in release it will actually perform the wrap. But there may be a compilation setting to change that behavior.

[github-actions]

This issue has become stale because it has been open 60 days with no activity. Adding the lifecycle/frozen label will exempt this issue from future lifecycle events.