
### Introduction 💬

We are able to compare Blockchain Developer to a sapper who only makes a mistake once. Once smart contracts are deployed in the blockchain, they are immutable from the nature. Although we are only human and anyone can make a mistake, especially when creating a complex system. What if the implemented smart contract turns out to be unrealible 😬, with a bug 😲 or we need to provide new functionality 🙄? Is there any solution to fix the above problems 🤔? The answer is YES 🥳🥳🥳! In this blog post, I write about the possibility of updating smart contracts (tokens), which will allow you to keep up-to-date with smart contracts and enable their expansion. The knowledge we gathered in the previous [Solidity: Delegatecall vs Call vs Library](http://blocksism.com/blog/solidity-delegatecall-call-library/) blog post will help us understand how upgradeability works in smart contracts underneath.

### Proxy Patterns ✏️

Proxy contract architecture predominantly relies on separation of responsibilities to two different contracts. First one, Proxy contract (immutable) which stores all data and the second Logic contract (mutable) which contains the whole logic. For the purposes of this post, we will often refer to Logic contract as Implementation contract. When we initialize transaction, all message calls go through Proxy contract which invokes Implementation contract via delegatecall. In the result, Implementation Contract works in Proxy Contract context. Upgradability while retaining data relies on Implementation Contract replacement by different implementation contract.

Let me present initial status before upgrade on the example below. Note that we are going to want to manipulate value variable with two functions in the contract where the logic resides.

![Upgradable smart contracts](https://blocksism-new-blog.s3.eu-west-1.amazonaws.com/upgradable-smart-contracts/upgradable-smart-contracts.png)

After the upgrade, relationship between contract will look like:

![Upgradable smart contracts version 2](https://blocksism-new-blog.s3.eu-west-1.amazonaws.com/upgradable-smart-contracts/upgradable-smart-contracts-2.png)

To update our smart contract, we need to **change the address** that points to the ImplementationContract (\_implAddr variable on the diagram) in ProxyContract to delegate calls to the **new contract** (ImplementationContractV2 on the diagram). Finally, we will keep our existing data and provide a new implementation.

### Let's write some code 🤓😃

Remember: Each version of the implementation contract must follow the same memory layout. What does it exactly mean 🤔? If we take example of the contracts below, there is one contract Proxy and the second contract Implementation. Notice that **both contract have the same variables in the same order.** By fallback function in Proxy contract we are able to delegate every call to Implementation contract where changes will take place in Proxy contract context.

#### Proxy Contract

```js
pragma solidity ^0.7.0;

contract ProxyContract {
   uint public value = 0;
   address implAddr;

   constructor(address implementationAddr){
       implAddr = implementationAddr;
   }

   function upgradeContract(address newImplementationContractAddress) public {
       implAddr = newImplementationContractAddress;
   }

    fallback() external payable {
        address implementationAddr = implAddr;
        require(implementationAddr != address(0));

      assembly {
        let ptr := mload(0x40)
        calldatacopy(ptr, 0, calldatasize())
        let result := delegatecall(gas(), implementationAddr, ptr, calldatasize(), 0, 0)
        let size := returndatasize()
        returndatacopy(ptr, 0, size)
        switch result
        case 0 {revert(ptr, size)}
        default {return (ptr, size)}
      }
     }
}
```

ImplementationContract

```js
pragma solidity ^0.7.0;

contract ImplementationContract {
    uint value;

    function incrementValue() public payable {
        value++; //increment by 1
    }

    function decrementValue() public payable {
        value--; //decrement by 1
    }
}
```

ImplementationContractV2

```js
pragma solidity ^0.7.0;

contract ImplementationContractV2 {
    uint value;

    function incrementValue() public payable {
        value+=10; //increment by 10
    }

    function decrementValue() public payable {
        value-=10; //decrement by 10
    }
}
```

Our task is to update the logic of our functionality from ImplementationContract to ImplementationContractV2 while keeping our previous data. First of all we need to deploy ImplementationContract and put it's address on ProxyContract creation and invoke incrementValue(), which should change value variable from 0 to 1. Let us assume that this action will simulate the performance of the system to date. Deploying the ImplementationContractV2 contract and using the upgradeContract(address newImplementationContractAddress) function in ProxyContract we are able to change the address of the logic contract to the new one we want to refer to. (ImplementationContractV2). From now all calls to ProxyContract will be delegated to new logic contract. Since the upgraded contract has a different implementation of the incrementValue() function, which increments value by 10 instead of 1, when it executes, we get 11. This shows that the number in value variable remained the same after the contract was updated.

Note that ALL references to the ProxyContract except upgradeContract() will be delegated to the logic contract. We can only achieve this by using the fallback() function by giving the first 4 bytes of the hash name of the function with parameters in the data. For a better understanding, I will not go into the web3 library. We'll only use one of its functions to get the hash, and I'll do the rest in the Remix IDE.

Remix IDE 🛠️
Working in Remix IDE, we are able to easily check the hash of the function we want to run using console with loaded web3 library.

```js
web3.utils.sha3('incrementValue()');
```

Where in the value of the sha3 function we give the name of the function we want to refer to.

In the case of the function named incrementValue() we get following hash:

```js
0x3bfd7fd3ec639bc48184934b65e95ac1cf6a287d453af5392bddef068bf12c31;
```

As I mentioned before we only need 4 first bytes to indicate a function. So the 0x3bfd7fd3 part is enough.

The next step is to call fallback() function and pass those 4 bytes in hexadecimal form in the CALLDATA input of 'Low level interactions' section of ProxyContract. If you do not know where the above-described fields are located, go to the screenshot below.

If you followed my actions in this post and worked as I did in the Remix IDE you should get a similar result as in the screenshot below.

![Screenshot](https://blocksism-new-blog.s3.eu-west-1.amazonaws.com/upgradable-smart-contracts/upgradable-smart-contracts-3-screenshot.png)

### Conclusion ✏️

You just learned how to create upgradable smart contracts. This knowledge will certainly be useful in your projects. It will leave you room for more maneuver and will also make you believe that smart contracts can be more flexible. However, flexibility comes with some risk. As you can see in the example above, we used low-level functions that are inherently risky. That is why I think that it is worth rely on the already existing libraries created by experts who have been working on them for many years, and it is them that we should base on when creating smart contracts.


Implementing upgradable smart contracts, tokens in Solidity programming language dedicated for Ethereum blockchain.

Solidity: Upgradable Contracts, Tokens


### Introduction 💬

One of the most important aspects in solidity programming are low level delegatecall, call functions as well as use of libraries. In this series of posts I gonna try to explain you how they work, in what context they work in as well as show you potential vulnerabilities ☠️ and unsafe ⚡ use.

First of all I want to emphasize that in this post I have used solidity version 0.7.0. I think that is a thing worth mentioning because of the dynamic development of the solidity language 😉.

### Demonstration Code ✏️

By these 30 lines of code below we are able to fish out and test necessary behaviours of the functions as well as the context which they are located. 😎😎😎

Take a look...

```solidity
      pragma solidity ^0.7.0;

      contract ImplementationContract {
          event testEvent(address txOrigin, address msgSenderAddress, address _from, uint msgValue);
          function doSomething() public payable {
              emit testEvent(tx.origin, msg.sender, address(this), msg.value);
          }
      }

      library ImplementationLib {
          event testEvent(address txOrigin, address msgSenderAddress, address _from, uint msgValue);
          function doSomething() public {
              emit testEvent(tx.origin, msg.sender, address(this), msg.value);
          }
      }
      contract CallingContract {
        address implementationContractAddress = address(new ImplementationContract());

        function callImplementationContract() payable public {
            implementationContractAddress.call{value: 0.5 ether}(abi.encodeWithSignature("doSomething()"));
        }

        function delegateCallToImplementationContract() payable public {
            implementationContractAddress.delegatecall(abi.encodeWithSignature("doSomething()"));
        }

          function callImplementationLib() payable public {
            ImplementationLib.doSomething();
        }
      }
```

In the code snippet we can distinguish exactly 3 entities. Going from the top there are **ImplementationContract contract** and **ImplementationLib library** where logic is implemented. Below them **CallingContract** as a third entity which we will use as a proxy to invoke logic using ours today's heroic functions: **delegatecall**, **call** and library call. (ImplementationLib) 🦸🦸‍♂️🦸🏻‍♀️

#### Graphical presentation:

![Diagram](https://blocksism-new-blog.s3.eu-west-1.amazonaws.com/simple.gif)

#### Transaction properties (tx.origin, msg.sender, msg.value) ✏️

Notice that **ImplementationContract** as well as **ImplementationLib** emit testEvents embodied as:

```solidity
       event testEvent(address txOrigin, address msgSenderAddress, address _from, uint msgValue);
```

They are emitted in **doSomething()** methods. Thanks to them we can easily elicit calling context with transaction properties depending on the function (delegatecall or call) used.

#### Let's run the functions and see the events' outputs for each call! 🔥

Working in Remix IDE, after contract deployment we have got following addresses:

- User wallet address: 0x5B3...dC4
- CallingContract address: 0xD7A...71B
- ImplementationContract address: 0xd84...397
- ImplementationLib of course has no address

Transactions have been invoked one by one with 1 ether in value.

| Function Call | tx.origin          | msg.sender                    | from                                 | msg.value |
| ------------- | ------------------ | ----------------------------- | ------------------------------------ | --------- |
| delegatecall  | 0x5B3...dC4 (User) | 0x5B3...dC4 (User)            | 0xD7A...71B (CallingContract)        | 1         |
| call          | 0x5B3...dC4 (User) | 0xD7A...71B (CallingContract) | 0xd84...397 (ImplementationContract) | 0         |
| library call  | 0x5B3...dC4 (User) | 0x5B3...dC4 (User)            | 0xD7A...71B (CallingContract)        | 1         |

&nbsp;
&nbsp;

### Conclusion ✏️

- Call

Now we are able to say that using call function to the ImplementationContract context changes, it calls an instance (instance here is an important word) of the ImplementationContract. Transaction properties are different in comparison to delegated call and library call.

- Delegatecall & library call

Delegatecall as well as library call do not change a context. It means that caller imports, pulls code into itself and uses calling function in its own context.

> Good to know 💡💡💡
>
> Futhermore, the example shows us **tx.origin** property behaviour. It gives the origin of the transaction. A tx.origin property address will be always a user wallet address.
>
> Stackoverflow: "In a simple call chain A->B->C->D, inside D msg.sender will be C, and tx.origin will be A."

### What's next? 🤔

Remember that using low level calls function can lead to devastating results. That's why we need to use them consciously. So... let's go to the next post and see potential risks ⚡ and vulnerabilities ☠️.

Moreover, knowledge of calls and delegatecalls is the key to understanding **Upgradable Smart Contracts**, which we discussed [here](/solidity-upgradable-token-contract


Difference between delegatecall, call functions as well as use of libraries.

Solidity: Delegatecall vs Call vs Library


### Introduction 💬

Applications that use blockchain wallets often face a problem with user authentication. Instead of using the traditional authentication method where the user has to provide a username and password, the user can use external wallets such as MetaMask or Portis. They provide the low level features of each wallet the ability to sign a specific message that will help us recognize and verify the user. In this post, I will walk you through a simple solution and give you a basic user authentication implementation the above wallets and ethereum cryptographic libraries together with JSON Web Token (JWT). If you are not familiar with JWT, please visit [this website](https://jwt.io/).

In general, the whole process consists of 6 steps:

#### Client

1. Establishing a message on which we will work
2. Signing message by the user (using private key implicitly)
3. Sending signature and user address to the server

#### Server

1. Verifying signed message
2. Generating JWT
3. Sending access token to the user

### Diagram 📌

As I am an advocate of presenting knowledge in a graphical way, I have prepared the sequence diagram below, which will help us in better understanding of the dataflow between parties.

![Diagram Image](https://blocksism-new-blog.s3.eu-west-1.amazonaws.com/user-authentication-via-wallet.svg)

### Implementation 🔥

Because of big interested in [NestJS](https://nestjs.com/), I have used this framework for backend side. Progressive framework facilities building efficient, scalable Node.js server-side applications and provides many embedded modules like @nestjs/jwt package. For client application I have used React as the most popular solution for building frontend side.

The entire implementation of this demo has been uploaded to the GitHub repository on my profile [here](https://github.com/mirooon/auth-via-wallet).

#### Client 📍

Major part of client code - signing the transaction is in the `LoginComponent` in `authenticate` method

```js
authenticate = async () => {
  const accountAddress = this.props.account;
  const signature = await this.props.web3.currentProvider.send('personal_sign', [
    getMessage(),
    accountAddress, //from which account should be signed. Web3, metamask will sign message by private key inconspicuously.
  ]);
  const signatureResult = signature.result;
  const requestOptions = {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ accountAddress, signature: signatureResult }),
  };
  //make request to local server
  return fetch('http://localhost:3001/auth/login', requestOptions)
    .then((response) => response.json())
    .then((token) => {
      this.setState({ access_token: token });
    });
};
```

Thanks to extended web3 library we have an access to many functions. To sign a message we have took adventage of `personal_sign` method where we need to pass two arguments:

1. **message** - data which we are signing, has to be the same and common for the client app as well as for the server
2. **account address** - from which account should be signed. Web3 library will sign message by private key implicitly. 💡

Isn't it easy to generate a signature? 🚀🚀🚀

![Simple GIF](https://blocksism-new-blog.s3.eu-west-1.amazonaws.com/simple.gif)

Now we are able to send the signature together with wallet address to our server 😄

Let's move on to the back-end side where the verification operations will be performed on the secure side.

#### Server 📍

If we look at the diagram, we are reminded that the backend has to recover the address and compare it with the one sent. Therefore, our application service comes into play with the code below.

```js
@Injectable()
export class AppService {
  constructor(private readonly jwtService: JwtService) {}

  loginUser(loginDto: LoginDto): string {
    const { accountAddress, signature } = loginDto;
    var recoveredAddr;
    try {
      recoveredAddr = recoverPersonalSignature({
        data: getMessage(),
        sig: signature,
      });

    } catch (err) {
      throw new HttpException('Problem with signature verification.', 403);
    }

    if (recoveredAddr.toLowerCase() !== accountAddress.toLowerCase()) {
      throw new HttpException('Signature is not correct.', 400);
    }
    //save your user here (i.e var user = await this.usersService.createWalletAccountIfNotExist(createUserDto);)
    const payload: JwtUser = {
      account_address: accountAddress,
    };

    const access_token = this.jwtService.sign(payload);
    return access_token;
  }
}
```

On input, the service takes the wallet address and signature. To recover the address, the service must use the function called `recoverPersonalSignature` provided by `eth-sig-util` library. The function also requires a shared message but this time the signature is passed instead of the address. ✔️

In the next step is to compare the recovered address with the address received from the user. If they are not equal, an exception is thrown. ✔️

Finally JwtService is injected into AppService in order to generate new access token for the user. ✔️

### Different approach? 🤔

A slightly more advanced and secure solution may be that the server generates an initial message that will require the user to sign this particular message.


User authentication via external blockchain wallets such as MetaMask, Portis. Instead of using the traditional auth method where you enter a username and password.

Blog

Latest Posts