-
Notifications
You must be signed in to change notification settings - Fork 0
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.
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
Gas Optimizations For BApps Token Matching #4
Conversation
Changes to gas cost
🧾 Summary (10% most significant diffs)
Full diff report 👇
|
uint32 sharedRiskLevel; | ||
/// @notice Represents a SharedRiskLevel | ||
struct SharedRiskLevel { | ||
/// @dev The shared risk level |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the encoding for beta is decided, we could add a comment here explaining it. Perhaps, we should reach a decision now.
Mathematically, the logarithmic encoding (
If so, we could stick to the linear encoding (
The type max value is
So, I think
What do you think?
@riccardo-ssvlabs @mtabasco @GalRogozinski
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Closing as discussed
Create a private function that unifies timelock checks like:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work @riccardo-ssvlabs ! Such great improvements in this iteration. Please check the comments. thanks!
src/interfaces/ICore.sol
Outdated
@@ -19,7 +25,7 @@ interface ICore { | |||
/// @dev The fee in percentage | |||
uint32 fee; | |||
/// @dev The proposed fee | |||
uint32 feeProposed; // TODO: here is transparent, but could be moved outside in a separate mapping? | |||
uint32 feeProposed; | |||
/// @dev The proposed fee expiration time | |||
uint256 feeUpdateTime; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we reduce the type for timestamp-related variables? uint32
or playing safe with uint64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On this, particularly with ObligationRequest
struct we can pack the data into 1 storage slot if we reduce the type of requestTime
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i prefer to use uint256 because block.timestamp returns uint256 and that will avoid unnecessary typecasting
Co-authored-by: MatheusFranco99 <48058141+MatheusFranco99@users.noreply.github.com>
No description provided.