2.6 State Variables: Definition, Visibility & Mutability

These are variables that can be accessed by all the contact functions. The data location where these state variables are stored is what is known as the contract storage.

Recall EVM has multiple components: the stack, calldata, volatile memory and the non-volatile storage. This non-volatile storage is where the state variables are stored because they need to persist across transactions that affect the contract state.

State Visibility

In Solidity, state variables have a concept known as visibility: who can see the state variables and who can access them. Visibility specifiers indicate this property. There are three specifiers:

• public: these state variables are part of the contract interface and they can be accessed either internally (from within the contract) or from outside the contract via messages.\

  For such public state variables, an automatic getter function is generated by the compiler, which is used to access their values.

• internal: these state variables can be accessed only internally; from within the current contract or contracts deriving from this contract.

• private: these state variables can be accessed only from within the contract.\

  They are defined at, and not even from the contracts that are derived from it.

Visibility specifiers are interesting from a security perspective because, although these seem to give an impression that certain state variables are private (in a sort of a privacy centric manner), everything that is within the contract is visible to all the observers external to the blockchain.

The private visibility specifier makes these variables private to the contract and prevents only other contracts from reading those private state variables on chain, however all the variables can be looked at can be queried via different interfaces.

State Mutability

State variables also have the concept of mutability. It indicates when can those state variables be modified and what are the rules for those modifications. There are two such specifiers

• constant: these state variables are fixed at compile, which means that their value is the same as when they were declared for the life of the contract.\

  There are certain rules for what expressions can be used for defining these constant variables within the contract.

• immutable: these on the other hand are fixed at construction time, which means that they can be assigned values within the constructor of the contract or at the point of declaration.\

  They cannot be read during construction time and they can only be assigned once.

The concept of mutability allows the Solidity compiler to prevent reserving any storage slot for these variables, making thesm storage and gas efficient: the gas cost of constant and immutable variables are lower.

The reason for this is because the expression that is assigned to it is copied to all the places where it is accessed within the contract and it's also re-evaluated each time. This aspect allows the Solidity compiler to make some local optimizations wherever constant variables are used. And in the case of immutable state variables, they're evaluated only once at construction time and then their value is copied to all the places in the code where they are used. For these immutable variables, 32 bytes are reserved even if they require fewer bytes.

Due to this, constant variables can sometimes be cheaper than immutable ones. For now the only supported types for these variables are strings and value types.