Skip to content
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

Fixed or non-fixed Solidity version pragma #19

Open
s-tikhomirov opened this issue Oct 3, 2024 · 0 comments
Open

Fixed or non-fixed Solidity version pragma #19

s-tikhomirov opened this issue Oct 3, 2024 · 0 comments

Comments

@s-tikhomirov
Copy link
Contributor

The contract uses a fixed Solidity version pragma:

pragma solidity 0.8.24;

An alternative approach is to use a ^ pragma, that allows compilation with future versions up to an excluding 0.9,0:

pragma solidity ^0.8.24;

We should make a reasoned decision on which option suits us best.

The following is a summary of pros and cons shamelessly copied from ChatGPT.

When to Use ^ and When to Use a Fixed Version:

  • Use ^ (with flexibility) when:

    • You want to benefit from non-breaking bug fixes, optimizations, or new features within the same major version.
    • Your project is in active development, and you're comfortable with upgrading the compiler within the same major version.
    • You have a thorough testing process in place to catch potential subtle changes that may arise from using a newer minor version.
  • Use a fixed version (without ^) when:

    • Security, predictability, and auditing simplicity are your top priorities, such as in large-scale or highly sensitive smart contracts.
    • The contract is deployed in production and doesn’t need new features or minor improvements. Fixing the compiler version can help maintain the same behavior and avoid subtle changes.
    • You are working in an environment with strict audit or compliance requirements where consistency is crucial.

Summary:

Feature ^0.8.0 (with ^) 0.8.0 (without ^)
Flexibility Allows minor updates and bug fixes Only uses the exact version specified
Predictability May introduce changes in newer minor versions Always uses the same compiler version
Security Updates Automatically benefits from security fixes in the same major version Requires manual updates for security fixes
Auditing Simplicity Auditing can be more complex due to multiple versions Easier to audit and reproduce behavior
Usage Suitable for active development, more flexible Suitable for production, more stable

The choice depends on your contract's use case and whether you prioritize flexibility or stability.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant