Update solidity contracts version dependency from fixed version to using ^ specifier

[jimmychu0807]

Describe the improvement you're thinking about

Update all solidity contracts version from:

pragma solidity 0.8.23;

to

pragma solidity ^0.8.23;

or to a version range that core developers agree.

Additional context
The reason is because Semaphore is becoming a library (building block) for dApp developers, and they integrate Semaphore into their dApp contracts. Using a fixed version specification 0.8.23 in Semaphore is restricting the solidity version used in downstream development.

There maybe a repercussion of updating zk-kit.solidity as well.

[cedoor]

Hey @jimmychu0807, as a good practice we've tried to keep those versions fixed to avoid any unexpected behavior.

Context: #115

But curious to know your opinion on this.

[jimmychu0807]

I agree there is actually a balance here, fixed version being restrictive and safe, and a wide version range being loosed and have a higher potential security risk.

A few thought points on this:

• If the set of smart contracts are gear toward being an end-product, then using fixed version is very reasonable. We don't expect other dev to integrate them. If the smart contracts are expecting to be a library that expect downstream developers to integrate, using fixed version is restricting them as well. As a reference, none of the openzeppelin contracts use fixed version. I am hitting this issue as I integrate Semaphore into ERC-7579 module and require 0.8.25 as the min solidity version.

• At this point Semaphore is becoming more and more like a library than an end-product. It provides zk functionalities that other dApps want to integrate. So currently, this restricts all downstream dApp contracts to use the solidity version Semaphore uses. Of course, they can always fork Semaphore repo and change it themselves.

• One possible (and more balanced) approach is making the version range to be restrictive such as pragma solidity >=0.8.23 <=0.8.28; The LTE version could be the latest solidity version that core dev team have tested and work with Semaphore. This ensures the security safety while giving downstream dev flexibility to pick their solidity version.

[cedoor]

One possible (and more balanced) approach is making the version range to be restrictive such as pragma solidity >=0.8.23 <=0.8.28; The LTE version could be the latest solidity version that core dev team have tested and work with Semaphore. This ensures the security safety while giving downstream dev flexibility to pick their solidity version.

I like this compromise!

Curious to hear @vplasencia's opinion here.

PR: #891