Skip to content

Add Math.modExp and a Panic library #3298

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.

Sign up for GitHub

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

Merged
Amxx merged 60 commits into from
Feb 2, 2024
Merged

Add Math.modExp and a Panic library #3298

Changes from 1 commit
Commits
Show all changes
60 commits
Select commit Hold shift + click to select a range
91e39eb
Added Wrapper Library for ModularExponentiation along with tests.
mw2000 Mar 27, 2022
712a0f3
Fixed linting issues.
mw2000 Mar 27, 2022
77f33ea
Added function to Math.sol and migrated tests.
mw2000 Apr 9, 2022
4683f26
Merge branch 'master' into modular-exponentiation-precompile-wrapper-…
mw2000 Dec 23, 2022
7489ce4
Merge remote-tracking branch 'origin/master' into modular-exponentiat…
mw2000 Jun 8, 2023
d576641
Added tests
mw2000 Jun 9, 2023
0d78d29
Fixed lint
mw2000 Jun 9, 2023
5d99ed8
Added changeset
mw2000 Jun 9, 2023
acb16f2
Merge branch 'master' into modular-exponentiation-precompile-wrapper-…
mw2000 Jun 9, 2023
d7e81cf
Fixed codespell error
mw2000 Jun 9, 2023
85187dd
Fixed function calling in tests
mw2000 Jun 10, 2023
d458765
Merge branch 'master' into modular-exponentiation-precompile-wrapper-…
mw2000 Jun 11, 2023
01badeb
Update contracts/utils/math/Math.sol
Amxx Jun 12, 2023
a1c1439
Added a restriction to e
mw2000 Jun 25, 2023
d81d69d
Merge branch 'modular-exponentiation-precompile-wrapper-#1985' of htt…
mw2000 Jun 25, 2023
6e8cced
Merge branch 'master' into modular-exponentiation-precompile-wrapper-…
mw2000 Jun 25, 2023
fd7b8de
All args should be non-zero
mw2000 Jun 25, 2023
26a036e
Seperating the e and m != 0 out
mw2000 Jun 25, 2023
4ba0a29
Fixed test when m = 1
mw2000 Nov 8, 2023
988c950
Merge branch 'master' into modular-exponentiation-precompile-wrapper-…
mw2000 Nov 8, 2023
c08ac50
Added last bracket.
mw2000 Nov 8, 2023
98f7994
Fixed lint issues
mw2000 Nov 8, 2023
f634aab
Merge branch 'master' into modular-exponentiation-precompile-wrapper-…
mw2000 Dec 24, 2023
66a0c1f
Added custom errors + tests for it
mw2000 Dec 24, 2023
eecd818
Added comments for errors
mw2000 Dec 24, 2023
1583160
Added a not to be reverted for custom error
mw2000 Dec 24, 2023
19ead8e
Merge branch 'master' into modular-exponentiation-precompile-wrapper-…
Amxx Jan 25, 2024
8cf355f
better fuzzing for modexp
Amxx Jan 25, 2024
113e85e
cleanup tests
Amxx Jan 25, 2024
4e1cf0d
Update .changeset/shiny-poets-whisper.md
Amxx Jan 25, 2024
6d7c154
return 0 instead of reverting in case of error
Amxx Jan 25, 2024
84b285d
fallback to revert
Amxx Jan 25, 2024
9e73f46
simplification
Amxx Jan 25, 2024
76c9afa
cleanup
Amxx Jan 25, 2024
1ff0776
Refactor fuzz test
ernestognw Jan 29, 2024
f84b1b6
Lint
ernestognw Jan 29, 2024
fe32a38
mulDiv fuzzing with no external
Amxx Jan 29, 2024
4accc2e
modExp in assembly to avoid memory leaks
Amxx Jan 31, 2024
cfd80e9
optimise and mark as memory-safe
Amxx Jan 31, 2024
526d6b9
add note about using Ferma's little theorem to compute inverse in big…
Amxx Jan 31, 2024
3718090
Add utils/Panic.sol library
Amxx Feb 1, 2024
cd2f2e9
add missing files
Amxx Feb 1, 2024
104002e
fix lint
Amxx Feb 1, 2024
d149ea6
mark constants as internal
Amxx Feb 1, 2024
05aa60e
slither disable
Amxx Feb 1, 2024
f352681
add unit testing for Panic
Amxx Feb 1, 2024
32ea4bb
Update test/utils/Panic.test.js
Amxx Feb 1, 2024
2e962c8
fix lint
Amxx Feb 1, 2024
275c959
Update Panic.sol
Amxx Feb 1, 2024
24cd52a
Implement tryMod
ernestognw Feb 2, 2024
50374a1
Implement review suggestions
ernestognw Feb 2, 2024
ee91836
fix tryModExp behavior and test
Amxx Feb 2, 2024
d13e52d
better vm.expectRevert check
Amxx Feb 2, 2024
969e259
use stdErrors for forge-std
Amxx Feb 2, 2024
e64c3f9
remove unecessary import
Amxx Feb 2, 2024
06220be
add a mock to force import libraries
Amxx Feb 2, 2024
9137bae
rename panic codes following libsolutil
Amxx Feb 2, 2024
81e8ba0
fix lint
Amxx Feb 2, 2024
2b72050
Merge branch 'master' into modular-exponentiation-precompile-wrapper-…
Amxx Feb 2, 2024
2fc20d4
Nits
ernestognw Feb 2, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Update Panic.sol
  • Loading branch information
@Amxx
Amxx authored Feb 1, 2024
commit 275c959d1e7a43cca009d40fc8c6fc57bc5e19c8
4 changes: 1 addition & 3 deletions contracts/utils/Panic.sol
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,8 +5,8 @@ pragma solidity ^0.8.20;
/**
* @dev Helper library for emitting standardized panic codes.
*/
// slither-disable-next-line unused-state
library Panic {
// slither-disable-start unused-state-variable
uint256 internal constant ASSERTION_ERROR = 0x1;
uint256 internal constant ARITHMETIC_UNDER_OR_OVERFLOW = 0x11;
uint256 internal constant DIVISION_BY_ZERO = 0x12;
Expand All @@ -17,8 +17,6 @@ library Panic {
uint256 internal constant TOO_MUCH_MEMORY_ALLOCATED = 0x41;
uint256 internal constant ZERO_INITIALIZED_VARIABLE = 0x51;

// slither-disable-end unused-state-variable

function panic(uint256 code) internal pure {
Copy link
Member

@ernestognw ernestognw Feb 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now anyone can call Panic.code(0xff) when 0xff is not in the "official" list (I'm not sure what "official" even means in this context).

I'm not sure how frequently Solidity adds (or changes) the panic codes, but imagine the following situation:

  • We release this Panic library
  • Some protocol start using Panic.code(0x420)
  • Solidity releases a new panic code in 0.9.0 using the same code (0x420)

Wouldn't it be bad that the same revert code has different meanings?

Copy link
Member

@ernestognw ernestognw Feb 1, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively we can generate this library procedurally wth the codes, such that users can do:

Panic.ASSERTION_ERROR();

Copy link
Collaborator

@Amxx Amxx Feb 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not too worried about users emitting random panic code ... but I'm not fundamentally opposed to making panic(uint256) private and having functions like

function TooMuchMemoryAllocated() internal pure { _panic(0x41); }

We would have to make them CamelCase though.

Copy link
Collaborator

@Amxx Amxx Feb 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The thing, if new panic code are ever added, the current version would allow users to use them without us having to do a release.
I'm also thinking, what if some L2 whant to use specific panic codes for some crosschain stuff. We won't want to add them to the library, but users will want to emit them.

Copy link
Member

@ernestognw ernestognw Feb 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We would have to make them CamelCase though.

Agree with this syntax.

The thing, if new panic code are ever added, the current version would allow users to use them without us having to do a release.

Right, good point. If the goal is to provide a workaround then I would be fine if we release the panic(uint256) function, although I'd suggest naming it _panic(uint256) and making it internal instead.

I know this is kind of the same thing but I feel the design of the library API is more friendly if we keep each panic code function and also the custom _panic for the following reasons:

  • The developers will have defined functions out of the box without the need to check the internal constants.
  • When using functions in editors like VSCode, the NatSpec shows up. Developers will have each panic code explained in their IDEs (I think this doesn't happen with the constants)
  • I realized it doesn't make sense for a protocol to rely on external contracts returning a panic code, it's easily exploitable and not 100% reliable anyway. It's worth keeping it but underscoring _panic helps signaling that the function is not intended for direct access but as a fallback for custom use cases.

Would you agree with this?

Copy link
Collaborator

@Amxx Amxx Feb 2, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The linter rules are not ok with that, and I think we should follow them:

  • Constant must be SNAKE_CASE
  • Library internal functions should not have leading underscore

The developers will have defined functions out of the box without the need to check the internal constants.

I'm not sure that is a good point. When testing panic code with hardhat you do

expect(...).to.be.revertedWithPanic(PANIC_CODE.ARITHMETIC_UNDER_OR_OVERFLOW)

you don't to

expect(...).to.be.revertedWithPanicArithmeticUnderOrOverflow();

Copy link
Collaborator

@Amxx Amxx Feb 2, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the current version is simple and effective. It's targetting advanced users anyway.

Copy link
Member

@ernestognw ernestognw Feb 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that is a good point. When testing panic code with hardhat you do

expect(...).to.be.revertedWithPanic(PANIC_CODE.ARITHMETIC_UNDER_OR_OVERFLOW)

Fair

I think the cureent version is simple and effective. It's targetting advanced users anyway.

We should document the function then. Currently it allows panicking with anything it I think it needs some usage instructions in both the contracts NatSpec and the panic funciton itself

/// @solidity memory-safe-assembly
assembly {
Expand Down