Used 'immutable' instead of 'constant' for keccak Variables

[0xScratch]

Usage of 'immutable' rather than 'constant' with variables storing the keccak hash saves some amount of gas.

Hope these links be worth it:

• https://gist.github.com/grGred/9bab8b9bad0cd42fc23d4e31e7347144#change-constant-to-immutable-for-keccak-variables
• "constants" expressions are expressions, not constants. ethereum/solidity#9232 (comment)

[iainnash]

I see – in normal situations you want to use constant since the optimizer can see it. Why can't the optimizer see that these keccak256s are static and preoptimize them?

[0xScratch]

Good question, I feel it's just the way optimizer works..Can't really define why it works this way. However, on asking AI about this, got this answer:

The Solidity optimizer is designed to perform a range of optimizations to reduce gas costs and improve contract efficiency. However, there are certain limitations to what the optimizer can optimize, including the pre-optimization of keccak256 operations on constant values.
The reason the optimizer cannot pre-optimize keccak256 operations on constant values is because the keccak256 function is a cryptographic hash function that operates on runtime values. The optimizer works primarily with compile-time values and cannot evaluate the runtime values during the compilation process.
In the case of constant variables, although their values are known at compile time, the keccak256 function still needs to be executed at runtime to compute the hash. This prevents the optimizer from optimizing the keccak256 operation because it cannot determine the runtime value of the constant variable during the compilation phase.
Furthermore, the Solidity optimizer primarily focuses on optimizing the bytecode produced by the Solidity compiler, rather than attempting to optimize the actual execution of cryptographic operations. Its goal is to reduce unnecessary operations, optimize storage access, and streamline the bytecode structure. Pre-optimizing keccak256 operations on constant values falls outside the scope of these bytecode-level optimizations.
While the Solidity optimizer is a powerful tool, it has its limitations. It's important to be aware of these limitations and consider them when writing and optimizing your Solidity code.

Moreover, many repositories kind of used this way...So there must be a reason for it. I will suggest reading some issues linked in ethereum/solidity#9232 (comment)
Probably you will find something interesting there in the discussions related to this

[oveddan]

looks good, needs to be updated to support new variables for premint v2

[iainnash]

This diff isn't possible given the way our contracts are structured:

Library cannot have non-constant state variables(9957)

Immutable variables can only exist on a contract level and these are declared on a library level. One thing we can do is to calculate those values ourselves, however this only exists in L2 state given the way we've structured our attribution contracts so the impact is lower.

We'll keep this in mind in the future.