Changing constant variable in inline assembly

[Muhammad-Abdullah012]

In hardhat-upgrades SmallProxy.sol, @PatrickAlphaC did

bytes32 private constant _IMPLEMENTATION_SLOT =
        0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

Which is basically declaring and initializing a constant storage variable.
Then, How does this work

function setImplementation(address newImplementation) public {
        assembly {
            sstore(_IMPLEMENTATION_SLOT, newImplementation)     // Changing the constant variable
        }
    }

Can constant variables be changed using inline assembly in solidity, why?? A constant shouldn't be a constant??

Link to teacher's repo

[krakxn]

Well, this will be complicated as Assembly is basically accessing the EVM, which is very low level.

So, I would suggest going through this first to understand what is happening here: #1219

sstore(p, v) 

is equivalent to

storage[p] := v

where p denotes the position on the stack.

So, to answer your question, yes -- we are assigning the constant variable here.

[Muhammad-Abdullah012]

You didn't even understood my question..

[Muhammad-Abdullah012]

My question is, The variable is a constant, which should not be changeable, ... why is it changing it??

[krakxn]

I already told you the "why" above.

"Assembly is basically accessing the EVM, which is very low level." -- This is why.

To keep it simple for you, think of it as playing a video game and directly changing settings in the code and not the game UI. The game UI is high level and will never override a hard-coded value.

Similarly, the same thing happens here. You will better understand it if you go through the LIFO/Stack model which Ethereum incorporates, as linked above.

But if you change the constant value directly in Solidity, it will not work. Because constant's cannot be initialized after their initial declaration. There is a difference between Solidity and Yul.

[alymurtazamemon]

@Muhammad-Abdullah012

We are not updating the constant variable here. I am not sure if you have cleared the concepts about proxy contracts or not. but let me give you an idea.

Proxies are one of the ways of upgrading smart contracts. How does it work? Whenever we want to upgrade our smart contract we create a new smart contract with all of the upgraded logins inside it and we call this implementation contract. Our proxy contract is like a Parent contract, its work is to redirect the users' function calls to the latest implementation contract.

Now, this is the location of the implementation contract storage slot according to EIP 1967:

bytes32 private constant _IMPLEMENTATION_SLOT =
        0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

We will update the implementation contract (if later any changes required) but the location of implementation contract remains same.

Hope it clears your query.

[Muhammad-Abdullah012]

@krakxn I've this doubt

[Muhammad-Abdullah012]

@alymurtazamemon

bytes32 private constant _IMPLEMENTATION_SLOT =
        0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

This has nothing to do with that, because it is not even using that implementation of EIP 1967, It is just storing EIP 1967 address and then reassigned using assembly with our own implementation of contract.

[Muhammad-Abdullah012]

According to docs:

The compiler does not reserve a storage slot for these variables, and every occurrence is replaced by the respective value.

For a constant variable, the expression assigned to it is copied to all the places where it is accessed and also re-evaluated each time.

This means that no storage slot is created; for the same reason, when we return only constant variable from a function, the function state mutability is pure (because it is not reading from storage slot).
My whole point of question is:
If reading a constant variable is not reading from storage slot, and constants cann't be reassigned, then how is

sstore(_IMPLEMENTATION_SLOT, newImplementation)

changing _IMPLEMENTATION_SLOT, why is storage slot being used (because constants are not written to storage slots)??

And all of this has nothing to do with EIP 1967, I tested it with remix using a simple contract:

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.7;

contract changeConstant {
    uint256 private constant v = 5;
    function increment() public {
        assembly{   
            sstore(v, add(sload(v), 1))
        }
    }
    function getValue() public view returns(uint256 result){
        assembly {
            result := sload(v)
        }
    }
}

It is also updating / changing value, and it gives 0 output for 1st time calling getValue (before increment()) instead of 5.

[alymurtazamemon]

@Muhammad-Abdullah012

@alymurtazamemon

bytes32 private constant _IMPLEMENTATION_SLOT =
0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;
This has nothing to do with that, because it is not even using that implementation of EIP 1967, It is just storing EIP 1967 address and >then reassigned using assembly with our own implementation of contract.

You have mentioned the same thing below that I was talking about.

[Muhammad-Abdullah012]

@alymurtazamemon

We are not updating the constant variable here.

You said this, but then you didn't explained what was sstore(_IMPLEMENTATION_SLOT, newImplementation) doing, which seems updating constant variable (original reason for asking question) .... You told about updating implementation contract... Then I asked same question with different code on stackexchange, I got my answer from there!.

[Muhammad-Abdullah012]

I got it.

According to docs

The compiler does not reserve a storage slot for these variables, and every occurrence is replaced by the respective value.

In this case :

//SPDX-License-Identifier: MIT
pragma solidity ^0.8.7;

contract changeConstant {
    uint256 private constant v = 5;
    function increment() public {
        assembly{   
            sstore(v, add(sload(v), 1))
        }
    }
    function getValue() public view returns(uint256 result){
        assembly {
            result := sload(v)
        }
    }
}

When
sstore(v, add(sload(v), 1)) is run, solidity compiler converts it into sstore(5, add(sload(5), 1)), and storage is an array, so it read / write in storage array at index 5. This is the key....
So when we write

sstore(_IMPLEMENTATION_SLOT, newImplementation)

solidity compiler converts it into :

sstore(0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc, newImplementation)

And read / write is done at this location in storage slot. (bytes32 converted to number and then used as index for read / write operations in storage array).

[PatrickAlphaC]

Nice work!

[albatros-github]

@Muhammad-Abdullah012 great but do you know why in the smallProxy.sol that uses "delegateCall" from import "@openzeppelin/contracts/proxy/Proxy.sol"; the vasriable "bytes32 private constant _IMPLEMENTATION_SLOT" doesn't clash with the implementation contract variable "uint256 public value;"