Blockchain Developer Path from ground zero #3

— Part 3

Hello little Padawan!

Here we go again. I hope you have had a wonderful time studying and reviewing the path (part I & part II). Today is going to be a test for your knowledge and I highly not recommend you to read this article if it is your first approach to blockchain development.

Without further introduction, as I promised, we will start with blockchain and smart contracts immutability.

Blockchain immutability

Up to this point, you already know that when any transaction gets minted into any blockchain, there´s no coming back. No possible regret about the information that has been saved will guarantee you will undo what has just happened. No ctrl+z possible.

Smart Contracts are immutable, aren´t they?

The same concept applies to Smart Contracts; Once an sc has been deployed to the network, the code bound to it is impossible to change. The storage variables that they have declared could change over time, but the associated code will not change at all.

Well, then a common question might pop out of your mind easily:

How do protocols like Aave or Uniswap release new versions without losing their storage in old Smart Contracts?

The answer behind the curtains that makes everything possible is delegate call; From official Solidity documentation:

When contract A executes delegatecall to contract B, B's code is executed

with contract A's storage, msg.sender and msg.value.

In more simple terms, this low-level function enables a smart contract to call a function from another sc, but it will use the storage from the smart contract that has originally made the first call to the mentioned function.

Let´s see an example to clarify it:

• Contract A (the one with the function we would like to call)

pragma solidity ^0.8.17;

contract A {
   uint public num;
   address public sender;
   uint public value;

  function setVars(uint _num) public payable {
       num = _num;
       sender = msg.sender;
       value = msg.value;
   }
}

• Contract B (the caller, who will call Contract A function)

pragma solidity ^0.8.17;

Contract Caller {
   uint public num;
   address public sender;
   uint public value;

   function makeDelegateCall(address AContract, uint _num) public payable {
        (bool success, bytes memory data) = AContract.delegatecall(
            abi.encodeWithSignature("setVars(uint256)", _num)
        );
  }
}

To conclude, a simple test table:

With this amazing feature that Solidity provides us, a main concept had emerged to solve the immutability problem: Proxies Smart Contracts.

Proxy Concept

A proxy (representative) is an agent or surrogate authorized to act on behalf of another person (machine or entity) or a document authorizing you to do so and can be used in certain contexts.

So basically a proxy is a representative that has the right to do things on your behalf. Also, a common way to see it is as a middleman.

The same concept is applied to Solidity to achieve Upgradeability.

Proxies Smart Contracts

To understand what Proxies smart contracts are, let´s first see the following diagram:

So now, we have two smart contracts:

• The Proxy Smart Contract will store the contract state.
• The Implementation Smart Contract will store the contract logic.

From now on, instead of interacting with your smart contract directly, your users interact with a proxy that only holds the state and delegates execution to a logic contract that holds the code. Upgradeability is then achieved by simply changing the reference to the logic contract in the proxy contract, so new code is used for executing all calls.

This can only be possible to delegate calls. Your smart contracts will be able to hold your state and not lose it, thus, enabling you to release new versions of something you always thought was impossible to change once created.

Currently, Open Zeppelin supports two types of Proxies; Transparent and Universal Upgradeable(UUPS) proxies. Both options are good to use, though OZ recommends using the UUPS ones. We will not go into detail in this article at least

The Diamonds: Another option to solve Immutability

A few years ago (2020), Nick Mudge released and then it gets approved as an ERC (ERC-2535) the Diamonds Standard under the description of a multi-facet proxy. It aims to solve the same problem but using a modular smart contract system. Due to its complexity, it will be covered and analyzed in another article but it is important to know it is another possible solution to upgradeable smart contracts.

Smart Contracts Standards

A bit of history first:

EIP & ERC are familiar concepts in terms of naming. ERC naming convention is nothing more than a copy from the RFC (Request for Comment) standards.

EIP — Types

This might even surprise a lot of you. EIPs are more than just ERCs. They involve several different types of improvements depending on the area they aim to enhance. Here you have the list:

• Standard Track
• Core
• Networking
• Interface
• Meta
• ERC: The current number of ERC nowadays is 307. From the official EIP website, it states:

Application-level standards and conventions, including contract standards such as token standards (EIP-20), name registries (EIP-137), URI schemes (EIP-681), library/package formats (EIP-190), and account abstraction (EIP-4337).

EIPs Path to become a standard

• Idea: A thought, not even a proper draft. It is not included in the official eip-repository.
• Draft: First formal stage of EIP. The proposal will be merged by an EIP Editor with the proper format.
• Review: The proposal after being thoroughly reviewed by its authors, will be marked as ready to be reviewed by colleagues. The EIP Author will mark an EIP as ready for and requests Peer Review.
• Last Call: Final review window for an EIP before its last state. An EIP Editor will set the last call review end date. In case a lot of changes might be required in this stage, the EIP will revert its state to Review.
• Final: The EIP gets finally approved. It is a standard from now on.

Deviations | Alternative states

• Stagnant: The EIP will get into this state if it is inactive for six months or greater in Draft or Review state. This does not mean the EIP will be discarded, it could be resumed and get back to the Draft state.
• Withdrawn: This means the EIP-Author(s) have withdrawn the EIP. This means the number assigned to the EIP could not be used again.
• Living: This is a special status that an EIP could get to be continually updated and not reach a state of finality.

There´s always more to come!